要有代碼
有人說，很快，代碼就會自動的生產出來，不再需要人工編寫代碼了。程序員完全沒有用了，因爲商務人士可以直接從規約中生成程序。
扯淡~ 我們不可能丟掉代碼。因爲代碼呈現的需求上的細節，在某些層面上，這些細節無法被忽視或者被抽象。我期望語言的抽象側此繼續的提升，也期望領域特定語言繼續增加，那是好事，但是終結不了代碼。實際上，在較高的層面上用領域特定語言編寫的規約也將是代碼！它得嚴謹，規範，精確，詳細，好讓機器理解和執行。
其實我感覺吧，這就是有了雞之後還需不需要蛋的問題，表明了 雞也得從蛋裏孵化出來。拋開了蛋，雞又怎麼產生。雞蛋不能生鴨子，所以還是需要鴨蛋~
糟糕的代碼
爲什麼寫糟糕的代碼呢？因爲是快點完成任務？因爲是要趕時間？或許你要乾的太多，花時間整理代碼會耽誤進程。或許你不耐煩的搞完這套程序，期望着早點結束。
我們都曾經的瞟一眼自己曾經造成的混亂，決定棄之不顧，走向新的一天。我們都曾經驚訝於自己寫的糟程序竟然能跑出結果，然後斷言能運行的程序總比什麼都沒有要強。我們都曾經說過，有朝一日再回頭清理。當然，那些日子裏我們都沒有聽過 勒布朗法則：稍後等於永不。
混亂的代價
混亂代碼的增加，團隊的生產力持續下降，趨於零。當生產力下降時，管理層只有一件事情可以做，那就是增加人手。可是新人並不瞭解這個系統，他們不清楚什麼樣的修改會符合意圖，什麼樣的修改違背意圖。他們頂着要提升生產力的壓力。於是，他們製造了更多的混亂，驅動生產力向零的那端不斷的下降，
態度
爲什麼好的代碼很快的就成了糟糕的代碼呢？理由多得很：愚蠢的經理，苛求的客戶….. ， 不過親愛的，我們不過是自作自受。你也許不願意聽，難道不關乎需求，不關乎進度的事情麼？不，經理只不過是指望從我們這裏得到必須的信息，然後才能做出承諾和保證。即使他們沒有開口問，我們也不應該羞於告知自己的想法。我們與項目的規劃脫不了干係。對失敗負有重大的責任。特別是當失敗與糟糕的代碼有關時
多數的經理想要好的代碼，即使他們總和是癡纏於進度，他們會奮力維護進度和需求。那是他們該乾的，你則當以同樣的熱情護衛代碼。在說些明白點，假使你是位醫生，病人要求你在手術前不要洗手，因爲那會花費太多的時間，你會照辦麼？ 本該是病人說了算，但是一聲絕對應該拒絕遵從。爲什麼？因爲一聲比病人更加了解疾病和感染的風險。醫生如果按照病人說的辦，則就是不專業的作法了
整潔代碼的藝術
你會問：怎麼才能寫出整潔的代碼呢？ 不過，如果你不明白整潔對代碼有何意義，嘗試着寫整潔的代碼就毫無意義！
壞消息是寫整潔代碼就像是繪畫，多數人能知道一幅畫是好是壞，但是不代表着會畫出一幅好畫。
寫整潔代碼需要大量的小技巧，刻苦習得”整潔感“。這種”代碼感“就是關鍵所在。有些人生而有之，有些人需要花費點時間才能得到。它不僅讓我們看到代碼的優劣，還與我們以戒規之力化劣爲優的攻略。
什麼是整潔代碼
- Bjarne Stroustrup ：
- 代碼邏輯應該直截了當，叫缺陷難以隱藏
- 儘量減少依賴
- 依據某種分層戰略完善錯誤之處的代碼
- 性能調到最優，省的別人做沒有規矩的優化
- 整潔代碼只想做好一件事，糟糕的代碼想做的事情太多
- 每個函數，每個類，每個模塊都全神貫注的做一件事
- Dave ：
- 整潔繫於測試之上
- 整潔便於別人修改
- Micheal Feather
- 整潔代碼總是看起來是特別在意它的人寫的
- Ron Jeffries
- 能通過所有的測試
- 沒有重複的代碼
- 體現系統中的全部設計理念
- 包括儘量少的實體
- Ward Cunningham
- 代碼讓編程語言看起來就像是爲了解決那個問題存在的
有意義的命名
軟件中的命名隨處可見，我們給變量，函數，參數，類和封包命名，我們給jar，war，ear文件命名，不斷的命名。既然有那麼多命名要做，爲什麼不做好它呢？
名副其實
名副其實說起來很簡單，我們強調的事是取個好名字要花好長時間，但是省下來的時間要比花掉的時間多~。而且一旦要發現更好的名稱，就要替換掉舊的。
變量，函數，或者類的名稱應該已經答覆了所有的大問題。它告訴你它爲什麼存在，它做什麼事情，應該怎麼用。如果名稱需要註釋來解釋的話，那就不算名副其實了。
int d //表示消逝的時間，以日記
int elapsedTimeInDays;
上面的兩個變量哪個好？
變量名稱不介意長，在能完全表達出意圖的名稱裏取最短的來用。
1 避免誤導
比如單詞Linux， File
你如果用Linux來命名蛋糕，用File命名糖果。這就是單詞誤導，好不如i，j這樣無意義的詞來得好~。
注意小寫字母 l 與 1 ，大寫字母 O 與 0 之間的相似之處。
int a = l;
if(O == 1){
O = 1;
}
這樣的代碼，叫誰讀起來都會發時間聯些什麼。
2 做有意義的區分
變量 a1， a2， a3 這樣的名稱純屬沒意義。他沒有向讀者提供寫意圖的線索。
ProductInfo 與 ProductData 雖然名稱不同，但是意義卻無區別。Info 與 Data 就像 a， an， the 一樣，是意義含糊不清的廢話。
廢話都是冗餘的。Variable 根本就不應該出現在變量中，就像 table 不能出現在數據庫表的命名中一樣。NameString 會比 Name 要好麼？ 難道 Name 還有浮點型的麼？ Customer 的類 和 CustomerObject 的區別何在呢？
3 使用讀得出來的名稱
程序裏面寫了 genymdhms 變量，這個由很多單詞字母塊組成的變量，怎麼讀？如果你跟別人交流的時候，難道還要搬着電腦問它這變量XXXXX麼？
4 使用可以搜索的名稱
int i 與 int timesCount哪個更容易被搜索？你不希望你Ctrl F 之後，滿屏都被標記出來吧！
類名
類名和對象應該是名詞或者名詞短語
方法名
方法名應該是動詞短語
你們不覺得對於類名，方法名，屬性 的命名，與其存在意義有很大的關聯麼？
別扮可愛，別用雙關
你認爲有意思的名字，不一定別人也認爲有意思。你用典故里的名字來命名變量，沒有讀過這個典故的人怎麼辦？怎麼理解？
寫代碼就像寫簡歷一樣，表達的東西要立竿見影，別人看見就能理解。
刪繁就簡，直擊主題。多看，多修改。
寫代碼不在於慢，而在於精
不是爲了寫代碼而寫代碼，而是爲了讀代碼
（跟寫文章差不多吧，寫文章不就是爲了給別人讀的麼？）