無暇的程式碼-敏捷軟體開發技巧守則(Clean Code)筆記

書籍介紹

這本書可以算是程式設計師必看的經典書籍之一了，Uncle Bob將如何寫出Clean Code的實踐方法，都寫在本書裡。
常常在扛爛系統的程式設計師看到這本書一定會有一些共鳴，像是函式的命名、註解、類別與結構的設計…等等，
把這本書讀完一遍，相信對你在維護與開發系統的工作上會有不同的想法。

什麼是Clean Code?

一次只專注一件事，不受周邊細節的干擾
有可讀性的Code
包含單元測試與整合測試

有意義的命名

選擇能展現意圖的名稱，不需要額外的註解解釋它
避免使用誤導的命名
使用能夠被唸出來、被搜尋的命名
避免使用匈牙利命名法(將變數型別寫入命名)
類別的命名應該使用名詞或名詞片語，避免是動詞
方法的命名應該使用動詞或動詞片語
每個概念只使用一種字詞，避免使用多個類似的字詞
使用解決方案領域命名，例如演算法名稱、模式(Pattern)名稱
使用問題領域的命名
添加有意義的上下文資訊

函式

簡短的函式
一次只做一件事
由上而下閱讀程式碼：降層準則
使用具描述能力的名稱
如果函式會轉換輸入的參數，轉換的產物應該包含在回傳值內
避免傳遞旗標值給函式，這樣代表函式做了兩件事，應該要重構成兩個函式
將指令(改變物件狀態)和查詢(回傳某些物件的資訊)分離
使用例外處理取代回傳錯誤碼
不要重複自己

註解

註解無法彌補糟糕的程式碼。用程式碼表達本意
有益的註解，包含法律型的註解、資訊型的註解、對意圖的解釋、對後果的告誡、待辦事項(TODO)
糟糕的註解，包含喃喃自語、多餘的註解、誤導型的註解、規定型的註解、日誌型的註解、干擾型的註解、出處及署名、被註解的程式碼、HTML型的註解、非區域性的資訊、過多的資訊、不顯著的關聯
可以使用函式或變數時就別使用註解

編排

程式的編排是一種溝通方式
一段程式碼代表一種思緒，用空白行來間隔這些思緒
有極度類似的概念，在垂直編排上應盡可能地靠近，避免使讀者在不同的檔案和類別中跳來跳去
變數宣告盡可能靠近在變數被使用的地方
實體變數應該宣告在類別的上方
相依的函式，在垂直編排上應盡可能地靠近，呼叫的敘述應該在被呼叫函式的上方
適合的水平寬度：不需要使用捲軸捲到右方

物件及資料結構

物件與結構不同之處：物件將他們的資料在抽象後方隱藏起來，將操作這些資料的函式暴露在外。結構是將資料暴露在外，沒有提供有意義的函式

錯誤處理

使用例外事件而非回傳錯誤碼
如果程式可能會拋出例外，在開頭先加上try-catch-finally敘述
提供發生例外的資訊
不要回傳null值，也不要傳遞null值

邊界

在邊界的程式碼必須能清楚的分割，並定義預期的測試，應避免讓我們的程式過度使用第三方軟體的特殊之處。
善用Adapter Pattern，將我們的介面轉換成第三方提供的介面，未來第三方軟體修改時，只需要進行極少處的修改

單元測試

測試程式與產品程式一樣重要
測試讓我們的程式保持擴充性，可以毫無畏懼的的改善系統架構
一次測試一次斷言，一次測試一個概念

FIRST 法則

Fast：快速
Indenpendent：獨立，一個測試不應該是下一個測試的設定條件
Repeatable：可重複性，可以在任何環境中重複執行
Self-Validating：自我驗證，測試程式應該輸出布林值
Timely：及時，撰寫測試程式要及時。單元測試要恰好在使其通過的產品程式之前不久撰寫

類別

類別要夠簡短
保持凝聚性會得到許多小型類別

Kent Beck的簡單設計原則

執行完所有測試
沒有重複的部分
表達程式設計師的本意
最小化類別和方法數量

平行化程式設計

與執行緒的有關的程式碼應該要短小且集中
將程式分為與執行緒有關與與執行緒無關的程式碼
不要鎖定那些沒必要鎖定的區域，避免從鎖定的區域呼叫另一個鎖定的區域

結語

這本書講了很多如何寫出Clean Code，不單是在Source Code的編排上，也特別提到的單元測試的重要性，有了單元測試保護，才可以毫無畏懼的去修改程式與系統架構，進而達到Clean Code的境界。雖然真實的專案中不一定都會依照Clean Code的精神開發，但看完這本書之後，我希望自己可以朝向Clean Code的方向前進，一次不用大規模修改，只要依照童子軍原則，簽入時讓Code比簽出時更為乾淨，以及加入單元測試，逐漸提高程式碼的涵蓋率。