《程式碼整潔之道》總結和筆記
前言
《程式碼整潔之道》在業內有很高的知名度，被諸多前輩推薦給後來者閱讀。本書以循序漸進改造一個小程式的方式，演示了一個程式可能的各種設計（在程式碼層面）。手把手教你該怎麼設計程式碼，為何要這樣設計，這樣設計的好處是什麼。通過一週的閱讀，總結了如下要點。
一 函式
所有的程式設計都是從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能迅速定位。
- 測試類應該儲存下來，方便每次修改後進行測試