軟體設計就是取捨之道

軟體開發領域很常用到「重新建造輪子」這一個句子，它是許多程式人常見的一種迷思，有時候，它甚至可以說是一種心病。

我們時常拿建造一個車子的過程，比喻開發軟體的過程。在這裡，車子是最終想要完成的系統，而輪子便是建造車子所需的重要零組件。因此軟體開發領域中，建造系統的重要軟體組件，時常被比喻為輪子。而重新建造輪子，自然意指重新開發系統所需的軟體組件。

重新造輪意謂生產力的耗費
為什麼說，重新建造輪子是許多程式人的共同心病呢？
這是因為許多程式人無法抵擋，心中那個呼喚、引誘他們重新打造輪子的魔鬼。為什麼要把重新建造輪子，說得好像是十分邪惡的一件事情呢？

無庸置疑的，軟體開發的生產力，絕對是現代軟體開發最看重的指標之一，也是許多軟體開發團隊所追求的重要目標。程式人在軟體開發上，除了確保品質之外，加速軟體開發的進程，同樣也是會面臨到的最大挑戰。

許多軟體專案的開發延遲，甚至遲遲無法完成，造成產品或服務推出市場的時間失去先機，這些多半都歸因於開發生產力不彰。因此，許多開發流程、軟體設計的技巧及方法，都著眼於提升開發生產力。

而輪子的重新建造，意謂著大量的生產力浪費。

新造組件耗費生產力，卻不見得可以得到好處
原本已經存在的軟體組件，在過去肯定花費不少時間，在需求分析、介面設計、程式撰寫、以及反覆的測試。而且軟體組件存在的目的，便是要讓多個開發專案共同運用。也就是說，每個軟體組件，都是經歷了許多專案現實又殘酷的考驗，才能生存下來的。

歷經這些考驗後，這些軟體組件等於是經過了廣泛的實戰測試，可能存在的軟體瑕疵，多半都已在測試中發現並修正。所以我們可以說，既存的軟體組件，可信賴的品質多半都有一定程度。

重新建造輪子背後代表的意義，是得重新再經歷類似的過程、投入資源及時間（通常占去最多的並不是開發時間，而是最容易被忽略的測試時間），最後得到一個或許可能比較好的組件。

但是這又如何呢？或許重新建造的組件的確優於舊有的組件，它可能更有彈性、更通用、適用範圍更廣、更多的專案可重複使用、滿足更多變的使用者需求。

但在你未來的系統中，這些優點不見得會完全地利用到，兩相權衡之下，不見得可以得到好處，但在當下是切切實實地把生產力給浪費掉了。

越優秀的程式人，越容易落入造輪的地獄
既然如此，為什麼程式人們總是會受到心魔的引誘，一而再、再而三地浪費寶貴的開發生產力呢？尤其我要說，越是優秀、對自我期許高的程式人，越是受不了這樣的誘惑。反而平庸的程式人，不容易發生重新建造輪子的問題。

這其中的原因究竟為何呢？讓我細細道來。雖然許多人都說，程式人這一行是吃青春飯，但我認為，程式設計終究是一個大量倚重經驗及視野的工作，而不是許多人心中所想像的，體力與對新技術的熟悉占極大的比重。

相信許多程式人和我有一樣的感受，每經過一段時日，就會覺得自己又「升級」了，基於這段日子的經驗累積，視野又大有不同。而這些「升級」的動力，例如學習、體會到某個設計方法論或是架構的好處。當你「升級」之後，再回過頭去檢視自己舊時的作品，多半會抱持負面的觀感。

面對過去的自己，時常會有一種「年少無知」、甚至是「年少輕狂」的感覺，真希望「昨日種種譬如昨日死，今日種種譬如今日生」。剛對設計方法或架構有了更深一層感受的你，對比起來，更明白過去所做的設計，究竟存在那些問題以及缺陷，它可能不夠通用、不夠彈性、也難以擴充。

倘若你是一個自我期許較高的程式人，免不了難以壓抑心中的衝動，這些問題及缺陷，便有如眼中令人難受的沙子，非得立即除之而後快。所以，對於那些既存，但又看不順眼的輪子們，會興起再次重新打造的念頭，也就不足為奇了。

可是，人總是持續成長，你的能力和視野，同樣隨著時間的演進，在不斷地進展。或許輪子的確不夠好，但在某個程度上，它是足堪使用的。

如果只是因為你知道有更好的設計方法或架構，就得要重新再把這些輪子再做過，無疑地，是陷入無止盡的輪子再造地獄之中，也持續地浪費無謂的生產力。或許有所得，但失去的更多。

堅持不重新造輪，也會引發疊床架屋這類的副作用
雖然重造輪子，會帶來生產力的浪費，但這也不完全意謂著，我們永遠不需要重新改寫既有的軟體組件。有些人剛好和喜歡重造輪子的人形成對比，他們總是不喜歡更動舊有的程式碼（通常稱為Legacy Code），因為他們深怕更動了舊有的程式碼後，會引發副作用。

當然，他們更不喜歡改寫既有的軟體組件，因為他們相信「做對的事，何必再改變」。何況，重新改寫更是一件浪費生產力的事情。
但是，這種堅持不重新設計所用軟體組件的想法，又會引發另一個問題，也就是舊有的組件，因為設計可能較為不良的關係，先天缺乏通用性的體質，無法因應新的需要，但你又不願意重新設計。

這使得你得採取繞路的方式，迂迴地達成目的，把額外的地方加諸在其他的組件，或甚至是你的應用系統之上。最後就是疊床架屋，持續地在不穩固的基礎上，繼續加蓋違章建築。而這種情境，在我們日常的開發生活中，其實也是屢見不鮮、時有所聞的。

軟體設計之道就是取捨之道
上述這兩種立場，看起來就像是天平的兩端、互相衝突，一邊的優點，正好是另一邊的缺點。這或許令人感到困惑，究竟什麼才是正確的態度呢？

我常說，軟體設計之道就是取捨之道。也就是說，不論做什麼設計決策，你都會得到某些東西，同時也會失去某些東西。而這中間的拿捏，端視你所在的情境，以及面對的目標而定。

我們形同要找到一個合適的支點，去支撐這有著兩個極端的天平，並且使之平衡。太過頻繁地重新建造輪子固然不對，但總不能在輪子的胎紋都磨平了，還勉強裝上車子並且行車上路吧？這中間存在一個適當的平衡點，而好的設計者，便會考量相關的背景因素，決定這一個平衡點究竟要設定在那一個位置。

對應到建造輪子的問題上，決定了一個好的平衡點，你就不會太過頻繁地重新建造輪子，但也不會總是使用同樣的輪子。你會決定適當的更新周期、汰換不合時宜的輪子，同時滿足新的需要。你在生產力和其他像是通用性之類的指標之間，取得了一個好的平衡。

怎麼決定支點在何處，是一門藝術，也是判斷設計者功力高下的所在。

作者簡介─王建興
	清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。