軟體開發者不應該自廢武功

2007/10/25 05:00:00 眾所週知，軟體開發專案具有高度不確定的特質。因此，為了降低需求變動的風險，在專案初期，軟體開發者往往會花費許多的心思，設計出具有彈性的軟體架構以適應未來可能的需求變化。大部分的開發者都了解軟體需求是不可能不改變的，但他們希望不管軟體需求如何變化，軟體開發的設計概念都不會因此受到影響或改變，如果可以做到這一點，軟體開發就會變得比較有效率，同時也能確保所開發之軟體的品質。

然而，現實總是和理想存在著一些落差，專案的演變往往會超乎開發者事先預期。尤其是當專案的驗收日期愈來愈接近時，專案可運用的資源也會愈來愈少，專案或許已不如剛開始時充滿了未知與不確定性，但相對地，專案的可變動性也愈來愈小。因此，在專案後期出現專案問題，或是需求的變動，相較於相同專案問題或需求變動在專案初期出現而言，會顯露出更為嚴重的危機與壓力的。

每個人都希望寧願事前多做一些風險管理，勝過事後的危機處理，而且後者的壓力是很容易讓做錯事的。然而，軟體易變的特質及專案環境的不確定性讓人難以捉摸，更不用說預測變化了，卻只能在事後才徒然留下「千金難買早知道，萬金難買後悔藥」的感嘆。但問題還是要解決的，到底軟體開發者在遇到這種危機時該如何處理呢？

軟體品質的問題

我們是否能拒絕變動？或許凍結需求，拒絕變動可以讓軟體開發成功，但卻不會讓專案成功。因為軟體專案如果無法符合軟體需求者的需求，專案並不能算成功，以軟體需求者的立場而言，客戶永遠是對的，他們並不在意技術有何難處，但卻會很關心軟體能否幫他們解決問題。所以，如果開發者所開發出來的軟體不能符合他們的需要、為他們創造出價值，軟體需求者會認為軟體品質並未達到目標，未符合品質目標，專案當然不能算是成功的。

如果變動無法拒絕，那麼只好接受它了，但這對軟體開發者而言，往往是重大挑戰。根據筆者參與軟體專案開發的實務經驗顯示，因為需求變更的原因，要向客戶去爭取專案合理的時程及增加開發成本其實並不容易。所以在專案時程與成本無法變動的情況下，想要解決專案的問題與滿足使用者的需求，很容易因此影響到產出軟體的品質。

其實從專案管理的三重限制（triple constraints）的觀念應不難瞭解到軟體品質與專案時程、成本及軟體需求之間常會相互影響，因此，當專案時程及成本無法變動時，我們很容易可以理解軟體需求的變動將會影響到軟體品質。

而在實務上，軟體開發專案常會時程壓力、專案得到的支援與資源不足等原因，使開發者沒有足夠的動機、時間、與精力來分析問題以設計合理的解決方案，取而代之則是直接修改程式，以符合軟體需求者所提出的功能，就算發現了因此將會破壞了設計上的結構也在所不惜。就短期而言，在設計的結構上做一些犧牲，雖然如此可以換取增加軟體需求者所提出功能的空間。但長期下來，缺少對問題分析與完整設計的系統，自然而然會衍生出許多軟體品質的問題。

解決問題的動見觀瞻

如此看來，軟體專案的需求變更，常會造成開發者的左右為難。計劃趕不上變化，現實就是變化無常的，所以藉由預測與控制要變動不發生是不切實際的。但擁抱改變似乎沒有想像中那麼單純，需求變化無常，程式碼也愈來愈複雜，造成更高的軟體出錯的機率，增添程式碼維護的困難度。

情況真的無法改變嗎？那也不見得，筆者認為想要脫離這種兩難的困境，開發者應先具有洞見（insight），認清軟體開發者應該面對的現實，但應該避免因為捨本逐末的行為模式而形成自廢武功的後果。

如下圖所示，表面上，忽略設計雖然可以省下時間來修改程式解決眼前的專案壓力，但因為環境仍舊不斷在變化，所以開發者忽略設計的狀況會一直持續發生。然而，長久的忽略設計，卻會影響軟體設計的概念完整性，結果將會產生軟體設計結構不良的後遺症，專案壓力最後當然會不減反增了。

當開發者長期忽略設計，他就不會花心思在軟體的概念性設計上，更不用說提昇軟體設計的抽象化思維的能力了。換句話說，開發者只能憑藉軟體實作的技巧來解決問題。但這是很危險的，因為程式碼只會愈改愈複雜，變得難以令人理解，同時溝通起來也會變得格外困難，出錯機會也就增加了，造成更多的專案壓力。

另一方面，長期忽略設計，設計的概念不夠完整，也就是設計會遺漏一些重要資料，因此設計無法重覆運用，而實作上又充斥了許多的特例，存在許多的資料細節，因此要重覆使用也會有困難。也就是說，軟體的設計缺乏完整及一致性，其實作又與業務邏輯之間產生複雜的相依性，因而軟體各元件缺乏再用性與彈性。用軟體開發領域中常聽到的話來說，就是開發者要不斷地重覆「造輪子」，軟體沒有足夠的彈性以適應需求的變化，專案壓力當然會一直居高不下。

由上述分析不難發現，提昇設計上的概念完整性對於軟體開發者而言，是非常重要的能力，因此，軟體開發者在設計上選擇讓步，無異於自廢武功，這樣將犧牲了設計概念的完整性，最後終究是無法解決問題或滿足客戶期待呀。

自廢武功無疑是下下策，但軟體開發者在面臨專案的巨大壓力下，要如何不自廢武功呢？我們下期再說。(待續)