設計：依賴WORD還是依賴WORLD？——談應對需求變更的軟體設計

"客戶說是這樣的！"，"客戶根本沒這個需求！"

需求對程式員而言，往往猶如聖經，客戶說了，我們就要這樣做。但是，往往客戶明天就變了一幅嘴臉，原本明明說好按鈕在下面的，結果現在一定要挪到上面去，明明不需要儲存顏色的，結果現在一定要把顏色也加上。於是我們從頭改到尾，從下改到上，好不容易改完，好了，客戶明天想法又變了！怎麼辦？繼續改！

 

好吧，厭倦了這種可怕的生活了吧，於是我們希望應對這種問題，於是我們決定，通過設計一個完美的架構來解決問題，我們希望，當客戶需求變更的時候，只要改改配置就可以應對。客戶不是一會喜歡讓Tab Header在上面一會喜歡讓Tab Header在下面嗎？那好，我就讓我的TabControl支援上下左右四種模式。客戶不是總是希望這個按鈕能點，那個按鈕不能點嗎？那好，我們就做一個許可權到按鈕。

 

這下好了，不過多出的開發時間怎麼辦？組裡的老程式員/架構師這個時候跳出來說，"小X啊，你要理解客戶需求啊，凡是客戶不要的，我們都不做。"，要麼就是"你這樣做，影響效能的啊！"，而且很可能，這些話會成為他對你工作的不良評價講給老大聽。

是不是很無奈？設計可擴充的程式，易維護的系統，就彷彿永遠是蠢驢面前用棍子吊著的胡蘿蔔，永遠因為項目進度，不能實施。你的才華，永遠無法被上司所理解。

 

問題出在哪裡呢？難道這就是軟體行業的現狀嗎？

 

當然不是！

 

其實很多人把"易於擴充的設計"曲解成了"包羅永珍的設計"。 我們要做的，不是窮盡使用者之所想，替使用者設想所有可能需要的東西，然後等使用者提出需求的時候，從中挑出一部分給使用者，而是更好的用程式反應系統的內在聯絡，在抽象過程中謹慎地保持和現實世界一致的可擴充性。

 

是的，客戶要你數農田裡的胡蘿蔔，你的程式裡不一定要有農田和蘿蔔坑這兩個類。客戶要你計算小鳥在火車中間飛的次數，你的代碼裡面也不一定要出現小鳥和火車字樣。

 

應對需求變更，不是衡量設計優劣的標準，即使再好的設計，當你的客戶要求把ERP系統變成學生選課系統的時候，應對的來嗎？

 

衡量設計的外在標準很多。比如，模組之間應該是高內聚，低耦合的；層與層之間，應該是單向依賴的；依賴關係應該是抽象的而非具體的；組件應該是易於複用的。這些是一個良好的軟體設計必然體現出的特性。而從本質上，設計應該更好反應問題的本質。

 

程式員應該從客戶的需求描述中理解客戶面臨的問題，進而設計程式去解決問題。前一陣愛民在w3ctech上講過，抽象分為共性抽象和本質抽象。不論使用哪種抽象方法，抽象過程都是去除不必要的資訊的過程。從情境中抽象用例，從用例中抽象特性，按特性設計程式，這樣設計出的程式，才能保持良好的可擴充性。

 

程式員應該是比任何人都瞭解這個世界的人，寫程式的過程就是不斷地抽象現實中的需求，並且用程式設計語言表達出來。程式設計之好壞，取決於程式員的抽象能力。程式設計之取捨，在於抽象的範圍和粒度。

 

PS.鑒於本文抒情性質明顯，不幸被提到以及被含沙射影的各位千萬不要扁我。