核心觀點#

作者 Robert C. Martin 在本章探討「簡單設計（Simple Design）」的概念。
他引用 Kent Beck 提出的簡單設計四原則，認為只要遵循，良好的系統架構與程式碼品質會自然而然地「羽化（Emerge）」成形。

這四條規則按重要性排序如下：

1. 執行所有測試
2. 沒有重複程式碼
3. 表達程式設計師的意圖
4. 最小化類別與方法的數量

設計不是一種靜態藍圖，而是一個動態演進過程。
透過撰寫測試並持續重構，我們能消除對修改程式碼的恐懼，讓設計隨需求持續優化。

簡單設計的四條守則#

1. 執行所有測試 (Runs All Tests)#

這是最基本也最重要的規則。

• 不可驗證即不可部署： 系統不能被測試，就無法被驗證；無法被驗證的系統，絕不該被部署
• 測試驅動設計： 為了讓系統「易於測試」，開發者會自然傾向撰寫遵守單一職責原則 (SRP) 的類別，降低模組間的耦合度
• 消除恐懼： 這是最大價值。當你擁有 100% 的測試覆蓋率，
  你就不會害怕「整理程式碼會破壞它」。這賦予了你重構的自由

2. 消除重複 (No Duplication)#

重複是良好設計的大敵。重複代表了額外作業、額外風險與不必要的複雜度。

• 從小處著手： 即便只是幾行程式碼的重複，也該被提煉出來重複利用
• 模組化： 透過消除重複，我們會發現某些邏輯應被抽象化，進而發現類別職責的邊界

3. 表達意圖 (Expresses Intent)#

大部分開發成本都花在「維護」上，而維護難度取決於閱讀程式碼的人能否理解你的意圖。
越清晰的程式碼，他人（或未來的你）接手時所需時間就越少。

• 勇於嘗試： 表達力的關鍵在於開發者願花時間修飾。寫完程式碼後，停下來看看：這容易讀嗎？
• 具體做法：
  • 選擇良好的命名
  • 保持函式和類別簡短
  • 使用標準命名法（如 Design Pattern 的名稱），善用專有名詞傳遞設計意圖
  • 撰寫良好的單元測試，測試本身就是最好使用文件

4. 精簡類別和函式大小 (Minimal Classes and Methods)#

這條規則是用來平衡前述規則，避免過度設計。

• 避免教條主義： 不要為了遵守某些死板規定（例如「類別都須有介面」、「欄位都須分開處理」）
  而造出大量無意義的微小類別或方法
• 實用至上： 雖然希望類別小、數量少，但「測試」、「消除重複」與「表達意圖」的重要遠高於此

重構的目標#

擁有了測試作為安全網，我們就可以開始重構。
重構不僅是為美觀，而是為了讓程式碼結構更健康。