前言
之前在網路上看到 Clean Code 系列的書，在網路上的評價是不錯的，因此就到學校圖書館借來看了，其系列著名的還有《 無瑕的程式碼 番外篇－專業程式設計師的生存之道 》和《 無瑕的程式碼－整潔的軟體設計與架構篇 》，也已列入書單。
此書以 Java 作為程式碼範例，從對於變數和函式的命名規則、如何將註解和縮排、物件和類別、單元測試、錯誤處理等寫得比較乾淨都有詳細介紹，也提到了許多軟體工程的專有名詞。但也因本書內容豐富，所以只整理了各章節個人主觀覺得重要的觀念，並略過了程式碼範例。
Ch1 無暇的程式碼
大致上在說幾個程式開發專家對於 clean code 的看法，總結起來有以下幾點:
Bjarne Stroustrup:
盡可能地最佳化程式效能
注意細節處，例如處理錯誤的程式碼必須完整，注意 Race Condition，memory leak，甚至是命名方式等
Dave Thomas:
重視可讀性，認為 clean code 是可被原作者以外的開發者閱讀和修改的
clean code 應經過單元測試和驗收測試
Ron Jeffries:
能通過所有測試
沒有重複的程式碼
充分表達系統設計的概念
具有最少數量的實體(包含類別，方法，函式等)
Ch2 有意義的命名
這個章節談的是變數/函式的命名方式，介紹幾個比較良好的命名規則
1. 產生有意義的命名區別
舉例來說，如果一個 Product 的類別，其後又有 ProductInfo 和 ProductData 兩個子類別，那就只是名稱不相同而已，並非意義上產生區別，因為 info 和 data 兩個意義太相近了
2. 類別和方法的命名
類別和物件應使用名詞來命名，例如 Customer，Account
方法應使用動詞來命名，例如 deletePage、getter 和 setter 使用 get 和 set 當字首，而判定用 is 當字首
3. 替每個概念(動作/行為)使用一種字詞，並持續使用
舉例來說，在為不同類別設定取得方法時，如果取用 fetch、retrieve 和 get 和全部只使用 get 相比，是否後者來的清楚和一致
4. 避免雙關語
雖然上一點提到為每個概念(動作/行為)使用一種字詞，但若是其目的不同，建議就使用不同的字詞，舉例來說，我們用 add 命名一個兩個數字相加的方法，而用 insert 將一個數字加入陣列
Ch3 函式
1. 簡短
作者提出個人經驗，建議函式的行數/內容要簡短，而且一個函式內只做一件事
2. 函式的參數不宜過多，避免超過三個
原因是可減少函式的複雜度，且做測試時，參數越少比較好做測試
Tip: 可以建立物件，把多個參數放在物件內
3. 使用例外處理取代 if else 做判斷後回傳錯誤碼
此外，把 try/catch 擷取出來成一個區塊，因為函式應該只做一件事
4. 使用具有描述能力的名稱
ex: isTestable()、includeSetupAndTeardownPages()
Ch4 註解
這章節講的是註解，在此章節的開頭作者提出，當程式碼呈現的意圖不夠明確時，才需要寫程式碼，否則就不必寫註解
1. 註解無法彌補糟糕的程式碼
與其花時間寫註解解釋混亂的程式碼，不如花時間整理它們
2. 有益的註解
有幫助的註解常用於:
- 資訊型註解: 說明回傳值，參數的意義
- 修改某段程式後果的告誡
- 放大某段程式的重要性
3. 糟糕的註解
- 誤導型註解: 寫了意思不夠精確的註解
- 規定型註解: 假如有規定說每個函式都必須有一個 Javadoc，或每個變數都要寫註解，這就是多餘的註解
- 一直被註解起來的程式碼: 在許多年前，被註解的程式碼可能是有用的，所以保留，但現在有版控系統，不需要一直留著被註解的程式碼
ch5 編排
程式碼的編排也相當重要，良好的縮排可增加程式的可讀性
垂直空白間隔
是用來分隔套件的宣告，library 的引入和不同的函式
水平空白間隔
單行不宜過長
團隊的共同準則
所有的團隊開發者都應該選擇同一種縮排風格並使用它
ch6 物件導向及資料結構
介紹程序式程式設計和物件導向程式設計的不同，提醒讀者根據情況選用不同程式設計的方式
使用資料結構的程式碼
將資料放在抽象層並隱藏，而且容易操作和新增函式
物件導向的程式碼
不易變動現有函式，但容易增加類別和資料
注意: 須避免出現以上兩者的混合體，只會集兩者缺點於一身
ch7 錯誤處理
使用異常處理(try catch)，而非錯誤碼
ch9 單元測試
說明測試對產品程式的重要性
本章重點:
- 測試程式和產品程式一樣重要
- 寫出整潔的測試程式最重要的就是可讀性
- 一個測試只測試一個功能
TDD 三大法則
- 第一法則: 沒有寫任何單元測試之前不可寫任何功能程式碼
- 第二法則: 只撰寫能夠呈現一種失敗情況的程式碼
- 第三法則: 只撰寫剛好能透過測試的功能程式碼
F.I.R.S.T 原則
整齊的測試應包括以下幾點:
- F(Fast): 測試速度應夠快
- I(Independent): 測試程式不應該互相依賴
- R(Repeatable): 測試程式應該可以在任何環境重複執行
- S(Selft-Validating): 測試程式應輸出布林值，不論有沒有通過
- T(Timely): 撰寫測試要及時，單元測試要在撰寫產品功能程式前寫
ch10 類別
介紹類別的簡潔寫法
重點:
- 類別不該包含過多職責/方法(類別要簡短)
- 保持類別的凝聚性。在方法內操縱越多變數，代表此方法更凝聚於此類別
單一職責原則(SRP)
此原則為物件導向設計 SOLID 五個原則之一，主張一個類別或模組應該只能有一個被修改的理由(職責)。
參考文章:
單一職責原則。到底什麼是改變的理由？
ch12 羽化
此章提出簡單設計四守則:
1. 執行完所有測試
透過單一職責原則創造小型單一用途的類別，使用相依性反轉原則(依賴反轉原則)最小化耦合性，不但改善程式碼架構，也減少測試的難度
2. 沒有重複的部分
3. 表達程式設計師的本意
意思是程式碼要有良好的可讀性
4. 最小化類別和方法的數量
單一職責原則不宜做過頭，因此要避免產生不必要的類別和方法，此點的優先權為四守則最低的一點
心得
筆記內容就到這裡結束，我覺得我的筆記還蠻簡潔的XD，在書中確實提出蠻多程式設計的原則，有些是我單看文字就能了解的，而且也有吸收到一些觀念，但有些是我覺得我需要實際進入到工作才會體會該原則和應用。總結來說，這本書是有用的，值得一看，希望我過幾年有機會再翻閱這本書時，能夠更深入體會它。想知道更詳細內容和程式碼範例，可以自行購買囉!
如果此篇筆記對你有幫助，不妨鼓鼓掌，這也是我寫文的動力來源之一哈哈，感謝你囉~
