星期四, 8月 10, 2017

[讀書] 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
  • 利用抽象化隔離修改



沒有留言: