Kent Beck 的四個簡單程式設計原則

什麼是好設計,打從開始 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。

參考資料

參與討論

1 則留言

發佈留言

發表迴響