程式者的胡言亂語
星期三 五月 02, 2007
淺談軟體設計的Over-Engineering
我們常常可以看到剛開始做軟體設計的人，往往不重視軟體架構，不在意可能會需要的彈性及擴充性，為了求速成，沒有在基礎架構上花心思，最後的下場就是一旦面臨了需求的變更，脆弱的基礎建設就禁受不住，最後的命運不是大改、重寫，就是繼續疊床架屋，在危樓上再蓋危樓。這種情況就是所謂的「under-engineering」。
不過除了上述的情況，我覺得另一種情況也時常可見，這種情況就是恰恰相反的「over-engineering」。這種「過度工程化」的情況，簡而言之，就是所謂的「想太多」。
under-engineering是絲毫不為日後的可能做準備，而over-engineering則是為尚不可見的未來做太多準備。這種情況的設計者，尤其是剛領教到軟體設計之美的設計者尤其會犯。這類的設計者會有太多的企圖，希望打造一個十分通用、最好是放諸四海皆準的設計。使得日後無論有多少變化，通通都能夠被納入在這個設計當中。所有的高手在追求的不都是大一統的通用性嗎？
很可惜的是，數學或物理上的大一統固然令人尊敬，但軟體設計上的通用性，時常要付出代價。以前我有提過，我認為設計包含著一連串設計的決策，在這些決策當中，必須在多項限制條件中去做取捨。做軟體設計的人，最能感受魚與熊掌不可得兼的道理。因為發揮到了極致時，取了效能就免不了要犧牲彈性，想要縮短時間，有時就得拿空間來換取。當你想要建立一個彈性極佳，可以應付未來各項需求的軟體設計時，時常意謂著的就是，請把你的效能貢獻出來吧！
這裡頭的關鍵就是，倘若你真需要那麼多的彈性，那麼換就換吧。但是，吊詭的是，其實你往往不需要如你想像中的彈性。建立一個無懈可擊幾近完美的一般化設計，除了美感外，別無用處。但軟體設計的目標並不在展現美感，而是要解決真實的工程問題。
先開火再瞄準是很有道理的。在over-engineering和under-engineer之間又要如何拿捏分寸呢？過與不及看來都有問題。你要做的並不是什麼設計都不做，也不是把設計做了過火。你要做的是，去建立一個具演化能力的設計，讓這個設計能夠隨時依照可見到的迫切需求，在很短的時間內滿足這個迫切的需求，同時繼續為下一次的演化而做準備。就是這樣，每一次的改變，除了滿足目前的需要之外，同時也為下一次的改變而做準備。
每個覺得自己是設計大師的人，總愛花太多時間在建基礎建設（我不是說建基礎建設不對，我想講的是，凡事都有個限度），忘了開發的本質是你要開發的目標。假設你要開發的是個像Web 2.0網路的系統，那麼需求的變化更是快速了。因為你會時常依著使用者的回饋，或網路所面臨到的現況，去做很多的改變。太多的預想時常只是落空，很多想像中的故事，其實常常不會發生。做了，只是浪費力氣，而且常常把效能都給浪費掉了。
在設計上這種情況叫over-engineering。在效能的最佳化上，這就叫做premature optimization－過早的最佳化。其實都是差不多的心態，只不過在不同的領域上發生。
Posted at 09:24下午 五月 02, 2007 by Chien-Hsing Wang in programming | 迴響[4]
不管你怎麼說，還是要生出一個java的新版本來啦。要不那種branch的狀況還是沒得解。XD
由...發表 singlelog on 五月 03, 2007 at 08:48 下午 CST #
[Trackback] 一個有紀律的開發者必須不斷地專注在面對「現實」，認清問題，用「目前最合適」的解決方法來解決。「現實」代表解答問題的目標是顯而易見的，所以我們可以輕易地寫程式來驗證目標......
由...發表 同人的生活派對 on 五月 23, 2007 at 06:53 下午 CST #
送你一個實例 引用恕不負責
我家有一個系統
用古老的C語言寫的
在P4 2.8的linux環境下 TPS(每秒交易量)大約是 150
整天被客戶幹
用的是啥鳥技術 幾百年前的東西
最近 終於有人用了客戶心目中最先進的技術寫了一套相同的系統
在 2CPU的IBM p590 AIX 環境 跑WAS 6.1 + MQ 6.0
TPS 2~3
結果呢？ 客戶爽到爆 因為這套系統連著的系統TPS只有0.3
所以他們感覺這套系統真是飛快
我在一邊 只有無言....
===============
順帶一提 你又把7777開起來囉 重溫舊夢？
一堆廢話 礙眼請刪除
由...發表 orson on 六月 04, 2007 at 10:02 下午 CST #
沒有耶, 我的 7777 的 source code 早就不知道扔到那去了 XD
應該是有熱心的user把它又架起來了
由...發表 Qing on 六月 06, 2007 at 01:09 下午 CST #