系統開發延續性的重要分類：系統

不可否認的軟體開發的程式設計師流動率很高，我想這個是全世界作系統程式開發人員供需不平衡所致，而台灣很多軟體公司因為一個高手離職，往往導致開發的時程受到很大的影響。

要如何解決這個問題呢？大部分想到的就是做好系統分析的文件，補足在開發過程修改的紀錄，而公家機關的做法往往是要求列印原始程式碼，但是我認為這個只是消極的做法，我想一個維護系統的公司倒閉，要較另一家公司接手，也是曠日費時。

最近看到微軟在宣傳新的平台，仔細地看清楚文件，原來這些都是兩年前的訂下的規格，目前只是重新包裝出來行銷而已（當然微軟也放棄掉很多自己訂的規格），而這兩年的期間我相信參與新平台的系統開發人員一定也是一直有更替，他們是如何延續當時的理想的呢？

我想有一個遠大的目標是不夠的，強制找出所有的系統模組的規則，並且認真的去討論內容，而且是讓每一個開發人員都了解為什麼要這樣做？不斷地演進我想這一句話說的容易但是做起來很難，光光開出一個規格一個模組就很難能讓所有的開發人員的意見相左了，還要去挖出對每一個模組要求的效率及通訊規格的一制性。

一個大的模組可能是一個人開發，但是大的模組裡面又有小的模組，比較難的是要求小模組之間的應用的正確性，人往往會有惰性，總覺得只要把要求的模組開發完成就好了，不管模組內部未來發展及維護的問題，我想即使是一個人開發，也是要依照上面的原則去思考系統的架構的。

而一個系統總是有歷史的軌跡的，面對一個新接手系統的人，一定要想辦法完全了解所有模組，為什麼要這樣子作？什麼模組是因為以前的電腦處理速度問題所做的最佳化？什麼模組是因為客戶專業性的重要需求所做的處理，我們往往會用現在的眼光去判斷以前的系統多麼不何時宜，系統架構多麼不好維護，但是總是沒有看到一個舊系統如何滿足客戶的需求及功能強大的優點。

系統開發不是水平分工的行業，如果光是靠資料庫就可以達成，或是靠建立一個網站就可以做好的話，這樣的進入門檻很低，也很容易在競爭的環境下被淘汰。所以，延續一個系統的強韌及不斷地開發是軟體開發人員先要了解的課題。