搞笑談軟工: 04/01/2014

2014年4月30日星期三

談談壞味道（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。

***

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

2014年4月29日星期二

史記和導入Scrum

Apr. 22 10:41~11:29

畫面節錄自coursera課程，史記（一）。

最近Teddy在coursera選了一門呂世浩老師所開設的史記（一）課程，在〈第六講吳太伯世家（主題：道德與成敗）〉的內容中，呂老師講到了「季札」的故事。關於季札的身平可以參考維基百科的說明，以及「季札讓國」的故事。

該週課程結束後，呂老師寫了〈聖達節，次守節，下失節〉這篇文章，讀完之後讓Teddy想到在台灣很多人在導入Scrum（或是任何其他軟體工程實務做法）所遭遇到的問題。

最理想的狀況，不管你所處的現況如何，你都可以改變它。能夠做到這個境界，與「聖人」無異，是所謂的「聖達節」。

但在現實生活中，能做到「聖達節」的人，少之又少。退而求其次，至少要能夠「守節」。你沒辦法說服同事寫單元測試，沒關係，至少自己負責的程式碼，都有做單元測試。別人不遵守coding standard，但你還是要按照規矩來。別人不追求開發軟體要寫出clean code，但你可以追求。如同呂老師所說的，這種選擇，並非消極的「明哲保身」，不管他人死活，而是在無可奈何之下的選擇。用自己的實際行為，來試圖感化自己的同事。謀事在人，成事在天。如果可以因此感化你的同事，當然最好；否則就是天意，只能順天而行。

最下等，如果連「守節」都做不到，就是「失節」了。反正大家都打混摸魚，程式「看起來可以動」就好了，有問題以後再說。什麼「軟體工程」都是學術界打嘴砲的說法，一點用處都沒有。東西做不出來怎麼辦？很簡單，就加班啊。只要「放大絕」，沒有解決不了的問題。

***

大部分的人，都不是「聖人」，但人都有理想，心中還是希望自己所處的團隊、公司，乃至於國家，可以達到「聖達節」的境界。因此，在「理想與事實產生落差」的時候，總是讓有理想、有抱負的鄉民們，感到非常的沮喪，最後甚至會從原本「聖達節」的出發點，直接向下沉淪到「失節」。這種心態的起伏，相信很多有心推動變革的鄉民，都曾經遭遇過。

想起2011年寫的〈都市游擊隊〉，是在讀了《建築家安藤忠雄》這本書之後，得到一個結論，就是不管大環境如何，至少盡力做到「守節」。

呂老師在〈聖達節，次守節，下失節〉說：「人生而在世，往往不能選擇自己出生所處的環境。如果你運氣好，生在了理想的時代、理想的邦國、理想的家庭，當然人生就不需要做出種種艱難的決定，這是一種莫大的幸運。但如果時代、邦國、家庭不如你所理想，你該怎麼辦？這是古今所有人共同面對的大問題。」

不僅是古今所有人共同面對的大問題，而且是「跨領域」的問題啊。

***

友藏內心獨白：知難行易啊。

2014年4月28日星期一

SOLID：五則皆變

Apr. 21 21:50~23:03

今年4月19日在上「Design Patterns這樣學就會了進階實作班」Day 1課程的時候，Teddy介紹了SOLID這五個物件導向設計原則。這五個原則出自於《Agile Software Development》這本書，就Teddy所知，Open-Closed Principle與Liskov Substitution Principle（又稱為Subcontracting）這兩個原則並非作者原創，因為Teddy曾經在《Object-Oriented Software Construction, 2nd》這本書讀過這兩個原則，至於其他三個原則就沒有在比這本書作者還早提出的其他文獻中讀過。

這五個原則的其中四個，Teddy曾經在部落格介紹過：

今天想要談一個問題，這五個原則都在講同一件事，請問是什麼事？

鄉民甲：明明就是五個不同的原則，怎麼會講同一件事？

***

原本Teddy也沒意會到這件事，就在上課前一天的晚上，Teddy在家裡備課的時候，把《Agile Software Development》這本書針對這五個原則的說明又讀了一次，才發現到，原來這五個原則，都在談「改變」這件事。

講的清楚一些，它們在談「面對原始碼改變的五種不同策略」，或是說「從五種不同的角度，來應付、管理原始碼改變」。哪五個角度？

SRP：降低單一類別被「改變」所影響的機會，在《Refactoring: Improving the Design of Existing Code》這本書中所提到的Divergent Change（發散式變化）就是一種類別違反SRP所形成的壞味道，類別設計符合SRP便可避免Divergent Change。
OCP：當新增需求的時候（功能變化），在不改變現有程式碼的前提之下，藉由增加新的程式碼來實作新的功能。
LSP：LSP談的是繼承，也就是透過繼承時子類別所造成的「行為變化」要如何設計，才可以讓程式在runtime透過多型所繫結（bind）到的子類別實作，不至於違反父類別介面的合約。
ISP：針對不同的客戶端，只開放其所需要的介面讓它使用，如此一來可避免與降低客戶端因為不相關介面改變也一起被迫需要改變的問題。假設你有一個擁有10個函數的類別，現在有三個不同的客戶端都需要使用這個類別其中的4、7、5個函數。如果直接把這個類別傳給三個不同的客戶端，則這些客戶端很可能會因為它所沒使用到的函數改變了，也被迫跟著改變（因為原本類別的介面改變了）。另一種作法，則是針對三個不同的客戶端，提供三個不同的Adapter。透過Adapter，只開放客戶端所需的函數給它們，以隔離因為不相關介面改變所造成的客戶端改變。
DIP：DIP談的是caller和callee之間的關係，在兩者之間增加一個（抽象）介面，避免caller（上層程式）因為callee（底層程式）改變而被迫改變。