最近由於一系列原因正在艱苦的啃書中（主要原因還是在面試的時候被教育了，確實發現自己沒有閱讀的習慣，這個習慣正在準備慢慢養成中），先感覺還是瞭解一下代碼的各種規範再說。
首先只能說這本書真的是驚到我了，我感覺之前工作中的代碼被批得體無完膚，真是慘，具體的細節和震驚到我的部分我會在下面詳細的列出來。
開篇的文章就對我來說很有共鳴感，之前的工作中也出現過這種的情況，之前的工作中有些需求因爲一直改動和工期的問題，我們就直接追求最後的結果，並沒有對於代碼的種種的冗餘性能之類的給予優化，因爲每次都是想說這個需求改動的太多了，我們先發上去之後我們再改。Clean Code開篇就提出了一個概念Later equals never，我感覺真是這麼回事，事實上之前工作中最後不合理的代碼只要沒有出現生產問題的事實上最後都沒有改動過.......
製造混亂無助於趕上期限，趕上期限唯一的方法——就是始終儘可能保持代碼整潔
第一章我們就簡單的有共鳴就跳過了，我們來總結下各個其他章節作者想教我們學會的事吧。
第二章有意義的命名
名副其實——最好要騰出時間來考慮屬性或方法的命名，而不是隨便給屬性和方法取一個沒有具體意義的名稱。
避免誤導——使用明確的區分度較大的命名，避免用會引起誤解的譬如O、l這種命名法
做有意義的區分——儘量使用明確的描述內容的名稱來定義類和屬性，避免類似info、data、Object此類的命名方式
使用讀的出來的命名方式——不要使用縮寫在代碼中進行命名
使用可搜索的名稱——使用靜態常量代替代碼中的常量
避免思維映射——不要用自己的思維映射方式來揣測其他人對於命名的理解
類名——類是用來描述一種具體事物的，不應當是一個動詞
方法名——方法是用來描述某一事物的某一動作的，應當是動詞或者是動詞短語
別扮可愛——不要使用俚語來進行命名
每個概念一個詞——使用同樣的概念，譬如getXXX
別用雙關語——在同種類型的操作中採用同樣的方法名，如果操作有所不同或者是實現或者是原理有所不同，請使用不同的方法重新命名
使用計算機術語進行命名或者是問題領域的名稱進行命名，這樣能夠使得下一個讀代碼的人能夠清楚的知道代碼的意義。
添加語境——可以在局部地點添加屬性和方法的語境，使用譬如JYXXX進行命名，但是請控制範圍，如果這個部分沒法造成區分，請不要添加。
第三章函數
函數這章核心想告訴我們的就是——一個方法做且只做一件事，並且短小到不能再抽取方法爲止。
只在一個抽象層級——注意函數在抽象層級上面佔據的位置不要躍層。
Switch——使用工廠和接口的模式來掩蓋switch函數
使用描述性的名稱——使用有意義的函數名稱，並且儘量的明確
函數參數——輸入的參數儘量少
一元函數的普遍形式——如果函數要對輸入參數進行轉換操作，轉換結果就該體現爲返回值。不要使用boolean作爲輸入參數。
二元函數——儘量避免，除非是單個值的有序組成部分，類似new Point(0,0)
三元函數——儘量避免，免不了可以使用新的類進行封裝
動詞與關鍵字——函數名字應體現函數動作和參數的關係，譬如writeField(name)
無副作用——注意函數只做一件事，儘量避免做除了函數名能描述之外的其他任何操作。
輸出參數——不要將輸入參數當作輸出參數來用
分隔指令和詢問——避免出現這種情況，一個函數動作如果成功返回A，失敗返回B，然後進行判斷，我們可以通過try/catch進行處理。
使用異常替代返回錯誤——充分利用java的錯誤處理機制來進行編程
抽離try/catch——try/catch中的每一塊內容應該就是一個獨立的事（函數）
別重複自己——使用面向對象的方法將代碼集中到基類避免冗餘
結構化編程——如果函數足夠短，出現return，break,continue並沒有什麼錯
怎麼做——我們不可能一次性就把代碼寫成這樣，所以我們可以慢慢的通過不斷的重構來慢慢優化我們的代碼結構。
第四章註釋
這一章的重點就是——需要註釋本身就是一種失敗，真正可讀性非常好的代碼不需要註釋，但是由於一般的侷限性我們還是需要註釋，那我們儘量把註釋寫的好些。
不要太過相信註釋，代碼纔是對於客觀現實最直觀的解釋。
好的註釋——對於意圖的解釋，對於晦澀的代碼的闡釋，對於關鍵內容的警告，TODO改寫沒有寫的代碼
壞註釋——由於SVN等代碼版本控制的出現，循規式的註釋、日誌式註釋、歸屬於署名
註釋掉的代碼、廢話、喃喃自語、誤導性的註釋等廢話，發現我之前的註釋大部分屬於這一種把，想想也真是個災難，由於之前的工作中代碼函數的不規範性，所以我當時在註釋方面還特別的給予了提示，按照書中的說法，大概都是廢話吧。