但是最近幾年的工作讓我有不一樣的心得，而不再費心追求「完美」的設計。同一個問題，每個人都會想出不一樣的解法，都說自己的解比較好。於是這些設計原則，常就淪為爭論的工具，當我覺得你的解法做太多事情時，搬出YAGNI; 當我覺得你的解法太複雜時，搬出KISS; 當覺得一個類別太肥大的時候，就搬出 SRP，反正都可以找到支持的論點就對了。很多時候其實不管哪一種方案，都是可以接受的可行方案，於是後來我就不想去爭個你死我活、斤斤計較當下的細節設計了。好設計應該是演進(grow)出來的，我首先在乎的反而是有沒有留下可用的測試和清楚好讀的程式，這樣才可以留下(後人)改進的機會。
回到正題，Kent Beck 在 eXtreme Programming 中，對於什麼是 Simple Design，留下了四個 Xp Simplicity Rules，我個人蠻喜歡的，因為很簡單又基本：
- Pass All Tests 通過全部測試：有測試才能夠讓軟體不斷的演進(grow)下去，不然你不是被 regression bugs 淹死，就是只能不計成本把code砍掉重練。如何寫好測試也是個大哉問，xUnit Test Patterns: Refactoring Test Code一書是其中的bible，嫌厚的話，可以先看看Refactoring Test Code這一篇paper，都是在講重構你的測試程式。當然，事情總是過猶不及，老闆付錢給你是為了得到 code，不是 tests。測試只是幫助我們寫好code的工具，追求100%完整的好測試並不是目的。
- Reveals Intent (Self-Documenting Code) 程式能夠表達出意圖：其中最重要而且基本的，就是要有好的程式命名，無論是類別、方法、變數等等。專講 Readable 的書有一本可以推薦 The Art of Readable Code。我這裡還推薦一個我最喜歡的技巧 Composed Method (搞笑談軟工也有一篇介紹)，這招也是 Kent Beck 大師提出的，將細節的實作抽取成一個小方法，讓整個方法裡的操作都是類似的粒度，小小一招，大有作用。
- 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 不只是在講不要重複程式碼而已。
重要性 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
Reference:
http://ihower.tw/blog/archives/7181?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ihower+%28%7B%7Cihower.tw%7C+blog+%7D%29&utm_content=Google+Reader
No comments:
Post a Comment