前言
《代碼整潔之道》在業內有很高的知名度，被諸多前輩推薦給后來者閱讀。本書以循序漸進改造一個小程序的方式，演示了一個程序可能的各種設計（在代碼層面）。手把手教你該怎么設計代碼，為何要這樣設計，這樣設計的好處是什么。通過一周的閱讀，總結了如下要點。
一 函數
所有的編程都是從HellWorld這個小函數開始的，學會設計函數非常重要
-
函數要短。短才方便閱讀、維護和設計。(每個人都經歷過讀不懂自己代碼的尷尬)
-
函數只做一件事。依照單一職責原則設計函數。一個函數可以:流程控制，邏輯判斷，改變變量狀態，以及做運算，或者調用多個下一抽象級的函數。
-
函數分解成多個抽象層級設計，高層函數只調用下次層函數，呈樹狀圖，層層封裝。
-
函數不應該有標識參數(除了作為API的函數)，這意味着函數有至少兩種執行方式，違反了第2條原則。而且明顯能拆成多個小函數。
-
函數參數越少越好有，多個參數應該封裝成一個整體傳入的。如果邏輯上不是一個整體，則函數肯定能被拆成多個小函數然后被分別調用。第4條標識參數可以封裝進整體傳入函數，而不是直接作為函數的參數
-
函數真的最好只做一件事，不要為了一時方便順手加幾行代碼。如登錄驗證時，函數用來驗證username和password，在驗證之后順便給用戶初始化些其他東西。會導致這個函數在其他時候無法驗證用戶信息。
-
底層函數不應該改變參數狀態，如果想改變某類的狀態，就把該函數加入該類，讓它自己調用函數。如：把改變類x的狀態的函數調用addFooter(x)，改為x.addFooter()。
-
函數不要返回錯誤碼，這需要你有錯誤碼的枚舉類，並且違反了開放封閉原則（你需要加入新錯誤碼來擴展新錯誤），直接拋出異常就好了。（可以通過繼承父異常來擴展）。但是實際上錯誤碼的應用不比異常少，而且異常也會導致代碼的臃腫。
-
函數名稱應該描述清楚函數作用，避免頻繁去看文檔，這對於短小的函數來說不難辦到，如果很難命名可能需要思考函數是否有依照以上原則設計(你一個函數可能做了很多事情)。並且名稱的命名應該不容易與其他函數名稱形成混淆。如：add()在calculator中意思是加，而在List中就不應該用add表示插入集合了，應該用insert或append。簡單來說就是一個概念對應一個詞，並且始終如一。
二 格式
每個人都有自己的編碼風格，書中總結了一些Java及其他語言的建議
-
好的格式應該由小且精的代碼片段（函數）組成
-
封包代碼，導包代碼，成員變量，函數方法。都用空行隔開，形成分開的代碼塊
-
函數按調用順序從上到下排列，類變量在頂端聲明，方法變量在使用前聲明
-
一行代碼不超過100個,同一行的計算可以按先后順序用空格隔開，如：
100 * 732 / (2+3) * (5-1)
小括號內的運算全都擠在了一起，其他運算都有空格隔開，很容易看出運算順序 -
縮進代表了一種包含關系。Java沒有強制要求，但是python就是用縮進表示包含。
-
說了這么多最后總結道：老大規定用啥格式就用啥格式
三 注釋
其實注釋寫了后，看的最多的還是自己
- 好代碼只需要少量注釋，代碼就能表達意圖——回到之前的內容，這要求我們寫小且精的函數。（但這不是你不寫注釋的理由）
- 好的注釋應該是這樣的。如：對抽象意圖或者深遠意義的解釋（如我這個函數為啥用這個方法實現）；闡述長且難讀的函數（這種難讀不是因為代碼寫得爛，而是業務邏輯復雜）；警示一些關鍵重要的部分（這些部分一般是函數會改變某些數據實體）；TODO注釋提醒並告知未來要做的事；學着公共API的JAVADOC寫就是好注釋（雖然也有少數爛注釋）；
- 爛的注釋往往是這樣的。如：多余的注釋（簡單函數強行加上注釋，讀源碼會比注釋更快）；誤導的注釋（注釋本來就是錯的，可能源自你更新了代碼沒更新注釋——小函數特別可能出現這個問題）；注釋掉的代碼（你為何不刪了代碼？）；廢話太多的注釋（語文是體育老師教的）。
四 類
書中對於函數的設計其實和類的設計思想是類似的，所以類應該功能單一且小巧，越小耦合性越低，最后用門面模式組合起來向外提供API就好了
五 系統
系統整體結構的設計
- 把系統的整體構造和業務使用分開。不要讓構造影響使用，也不要讓程序的運行反過來影響構造。這也是Spring這么應用廣泛的原因之一，Spring Core就是個類容器。
- 把業務邏輯和檢查或日志方案分離，不然糾纏在一起的代碼會很難看懂和修改。Spring AOP也解決了這個問題。
六 測試
測試不僅僅是測試小姐姐的事情
- 測試函數（方法）也應該短小（如果函數原本夠小的話測試函數自然會小）
- 每個類最好都測試下，測試時間會比以后debug時間少。從底層函數一點點測上去，以后debug能迅速定位。
- 測試類應該保存下來，方便每次修改后進行測試