[讀書] Clean Code: A Handbook of Agile Software Craftsmanship 上

最近公司 TenMax 的研發團隊完成了 Clean Code 這本書的讀書會，我自己覺得這本書很有趣，尤其在一個成熟的研發團隊正在開發或維護大型軟體，裡面有很多好的準則常常會在Plan Meeting 或是隊友在討論開發細節的時候常常聽到，「這個寫法有沒有 Clean Code 阿?」。

趁熱筆記一下個章節的速記

第1章 無瑕的程式碼 - Clean Code

• 簡介一些大師眼中何謂 Clean Code。

第2章 有意義的命名 - Meaningful Names

• 命名是程式中最難的事情，提供了一些避免跟建議的命名方法。

第3章 函式 - Functions

• 簡短，只做一件事情原則，才能算是好函示。
• 降層原則，讓閱讀函示像是閱讀文件。
• 函示的參數小於等於2最理想。

第4章 註解 - Comments

• 註解的目的
• 快速回憶上下文
• 瞭解開發者意圖
• 最好的註解就是程式本身

第5章 編排 - Formatting

• 編排是團隊的一個共同溝通方式
• 每一段程式碼都代表一個完整的思緒，可用編排( ex :空白行)來分隔思緒。
• space or tab?
• function { } carriage return ? 

第6章 物件及資料結構  - Objects and Data Structures

• 資料的抽象化
• 結構化的程式碼難以添加新的資料結構，因為必須改變所有的函。
• 物件導向程式碼難以添加新的函示，因為必須改變所有的的類別。
• 物件還是資料結構
• 物件(Object): 暴露行為並隱藏內部資料
• 資料結構(Data Object): 暴露資料但不會有行為
• 德摩特爾法則 (The Law of Demeter)

假設下面的程式碼

Result result = myObject.myMethod(ctxt)

那myMethod應該只能用到

1. 自己: myobject
2. 傳進來的參數: ctxt
3. 回傳的結果: result
4. 自己所持有的物件: myobject.ooo

第7章 錯誤處理 - Error Handling

• 讓錯誤的意圖變的明顯
• Checked Exception vs Unchecked Exception
• 在不正確的地方寫錯誤處理，導致邏輯混亂，例如該正確運行的地方還加上處理
• 錯誤處理，依照撰寫者意圖應該要有兩種形式
• 嚴重錯誤
• 應該要被完整處理的情況

第8章 邊界 - Boundaries

• 探索與學習邊界: 常見案例，整合第三方軟體
• 學習性測試:
• 不要在產品程式實驗新的東西，而是額外撰寫程式程式來探索第三方軟體

第9章 單元測試 - Unit Tests
內容很多，尚待補充

第10章 類別 - Classes

• 類別就是一種封裝的方式
• 類別要夠簡短，命名是一個判斷的方式，如果無法取一個簡明的名稱，他負責的東西可能太大了。
• 是否能用簡短的方式敘述一個類別的目的。
• 單一職責原則（Single Responsibility Principle SRP)， 主張一個類別或一個模組應該有一個，而且只能有一個修改的理由。
• 保持類別的凝聚性，可能會得到許多小型的類別。
• Open To Change
• 利用抽象化隔離修改