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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

作者簡介─王建興

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

 

 

熱門新聞

Advertisement