談談壞味道（7）：Lazy Class & Speculative Generality

Apr. 25 11:03~12:12

照片節錄自網路。

 

Lazy Class（冗員類別）

政府機關與公司等組織一樣，隨著時間的演變，組織內多多少少都存在著一些「冗員」，也就是領錢不做事的人。如果真的只是領錢不做事也就罷了，冗員為了不讓自己看起來那麼沒有價值，三不五時發表一些似是而非的言論，扯其他做事的人的後腿。

程式中也經常存在「冗員類別」，這些類別當初被「應聘」到系統中的時候，通常被賦予若干有意義的責任。但隨著系統修改與重構，這些原本「胸懷大志」的類別，不是派不上用場，就是原本被賦予的責任已經轉移到其他類別的身上，逐漸變成了人人喊打的「冗員類別」。

照理說如果程式執行得好好的，沒有發生問題，「冗員類別」的存在似乎不會對系統造成重大傷害。但程式是寫給人看得，日後有人要閱讀程式碼，很可能會被「冗員類別」的存在形成懷疑，要刪除也不是，留著又很礙眼。長此以往，系統中的「冗員類別」越來越多，系統也就變得越來越難以理解。

***

綜合以上的說明，lazy class之所以會是一個bad smell的原因（force）可歸類為：understandability和modifiability這兩點。

移除lazy class壞味道的方法，在《Refactoring》書中提到可以套用Collapse Hierarchy與Inline Class。

***

Speculative Generality（夸夸其談未來性）

Speculative是「推測」、「臆測」的意思，generality是「一般性」，兩個字合起來的意思是「在作設計的時候，預留了太多未來可能會用到的擴充點」，中文版的《Refactoring》將其翻譯成「夸夸其談未來性」。

在早期敏捷方法尚未流行之前，很多軟體工程師受到的設計訓練，都是強調「要替未來的擴充性預作準備」。但因為大家都不是算命仙，對於未來的諸多猜測，要嘛不是沒有發生，就是因為需求改變了而造成猜測錯誤。「夸夸其談未來性」所造成的big up-front design（過多事前設計），不但是一種資源浪費，也會增加日後軟體修改的困難度，所以慢慢地大家接受了敏捷方法的觀點，只做足夠的設計，用精實開發的術語來說，就是盡量延緩決策的時間點。

過多、過於彈性的設計，會增加系統的複雜度，降低理解性，因此也增加修改的困難。同時，因為複雜度增加，測試的困難度也隨著提升。

***

綜合以上討論，speculative generality之所以會是一個bad smell的原因（force），可歸類為：understandability、modifiability、testability這三點。

移除speculative generality壞味道的方法，在《Refactoring》書中提到可以套用Collapse Hierarchy、Inline Class、Remove Parameter和Rename Method。

***

友藏內心獨白：為明天而準備是軟體工程師的習慣啊。