什麼是好設計，打從開始 coding 以來就是一個不斷追求的大哉問，從
SOLID 看到 Design Patterns，每一個原則看起來好有道理，每一個設計模式都在等著你的套用。

但是最近幾年的工作讓我有不一樣的心得，而不再費心追求「完美」的設計。同一個問題，每個人都會想出不一樣的解法，都說自己的解比較好。於是這些設計原則，常就淪為爭論的工具，當我覺得你的解法做太多事情時，搬出YAGNI; 當我覺得你的解法太複雜時，搬出KISS; 當覺得一個類別太肥大的時候，就搬出 SRP，反正都可以找到支持的論點就對了。很多時候其實不管哪一種方案，都是可以接受的可行方案，於是後來我就不想去爭個你死我活、斤斤計較當下的細節設計了。好設計應該是演進(grow)出來的，我首先在乎的反而是有沒有留下可用的測試和清楚好讀的程式，這樣才可以留下(後人)改進的機會。

回到正題，Kent Beck 在 eXtreme Programming 中，對於什麼是 Simple Design，留下了四個 Xp Simplicity Rules，我個人蠻喜歡的，因為很簡單又基本：

1. Pass All Tests 通過全部測試：有測試才能夠讓軟體不斷的演進(grow)下去，不然你不是被 regression bugs 淹死，就是只能不計成本把code砍掉重練。如何寫好測試也是個大哉問，xUnit Test Patterns: Refactoring Test Code一書是其中的bible，嫌厚的話，可以先看看Refactoring Test Code這一篇paper，都是在講重構你的測試程式。當然，事情總是過猶不及，老闆付錢給你是為了得到 code，不是 tests。測試只是幫助我們寫好code的工具，追求100%完整的好測試並不是目的。

2. Reveals Intent (Self-Documenting Code) 程式能夠表達出意圖：其中最重要而且基本的，就是要有好的程式命名，無論是類別、方法、變數等等。專講 Readable 的書有一本可以推薦 The Art of Readable Code。我這裡還推薦一個我最喜歡的技巧 Composed Method (搞笑談軟工也有一篇介紹)，這招也是 Kent Beck 大師提出的，將細節的實作抽取成一個小方法，讓整個方法裡的操作都是類似的粒度，小小一招，大有作用。

3. No Duplication (DRY) 不重複：”Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” 完整定義請複誦三次。有時候重複並不是這麼明顯，例如作用重複的程式，但命名不同，或是命名重複，但程式作用不一樣。這裡推薦 David Chelimsky 的影片 Maintaining Balance While Reducing Duplication (slides)和 Maintaining Balance while Reducing Duplication: Part II，可以增進對 DRY 的理解，DRY 不只是在講不要重複程式碼而已。

4. Has no superfluous parts (Minimizes the number of classes and methods) 不多餘：這一條也就是 YAGNI，不要實作多餘的功能。我個人不怎麼喜愛這個原則。不是不贊同，不需要的功能花時間去寫當然是浪費大家時間，而是這個原則太容易例外了。有時候會寫下多餘的程式來增加功能或擴充性，那是因為你擁有的經驗、直覺跟當時的情境告訴你應該這麼做，這可以在不久的將來就派上用場，過於強調 YAGNI 反而一板一眼教條主義了。光單看”減少類別跟方法的數量”跟 SRP 和 Composed Method 就有所衝突了，後兩者都會增加類別和方法的數量。

重要性 1 > 2 > 3 > 4，也有版本講 1 > 3 > 2 > 4。

參考資料

• Xp Simplicity Rules
• Agile in a Flash: Simple Design
• The 4 rules of simple design
• Clean Code: Four Simple Design Rules – Obligatory Read