S23 專案問題產生原因之可能破解

專案時程給得過於緊迫會有這幾個後遺症：功能急著想完成忽略所有可能的例外、SA與SD收集分解動作的不完全、動作難以抽取或分派形成過多的重覆程式碼，最終造成難以調整的複雜結構。根據以上問題我採用的應對方式是從後面開始解決起。

首先是適合調整的軟體架構，依之前提到的軟體結構設計出放置程式的Class，確保每一個分解動作的程式都是分離且容易移動的。其次是找出適合SA與SD使用的工具軟體，在分析設計每一個Use Case的同時還能以整個系統的角度來思考與放置。最後則是具有大量元件的函式庫，分析設計出來的分解動作在以前若已經依理想的方式包裝成元件，那麼應該有理想的解法同時包覆著許多例外狀況的處理而能夠直接引用，考慮的重心就可以移到多個Use Case共用時產生的各種條件變化。

公司在數個專案間有共用的Jar File，在其中一個專案上線後根據其他專案遇到的問題陸續修改了其中一個。後來在上線專案那邊找到同一個Jar File的重大改變，但是我只敢改在原來的檔案裡而無法直接更新為最新的版本，因為我無法保證沒有side effect。主管說多測試後就可以用，我回答說就算投入一百個人測試，只要沒測到全部的流程就有可能出事，全部的流程卻又是眼前無法提供出來的。

就像以前提到的紅豆與綠豆的例子，在不分類的狀況下全丟在一起是很快完成的，但是未來遇到想分開的情況時會花更多時間。剛開始只求功能的完成，只要豆子的總數對怎麼放都無謂，但是在專案到尾聲時任何一個變動都可能牽一髮而動全身；如何拿出可以掌握任何改變的關聯與影響的追溯結果，正是維持品質的關鍵因素。