許多長期運作的系統仍提供重要功能,卻因文件不足、缺少測試、相依關係混亂或技術停止支援,逐漸難以理解、修改與部署。這類系統通常稱為遺留系統(Legacy System)。
本系列以「重新設計並建置目標系統,最終替換遺留系統」為主線,內容涵蓋需求與範圍確認、舊系統分析、目標設計、功能重新實作、測試、正式切換及舊系統退場。
系列不預設特定框架或架構,適合正在維護長期運作系統、準備替換既有系統,或希望建立完整重構流程的開發與維護人員閱讀。
重複的程式碼過多,如何使用框架改善架構? 前面已經選定目標系統使用的框架(Framework),也建立了相依項目的管理方式。接下來要把框架提供的結構與生命週期用...
程式碼應該遵循哪些規範? 前面已經選定目標系統使用的技術,固定開發環境與相依版本,也確認框架及共用元件的責任。開始實作功能前,還要把這些決定轉成全體開發人員都能...
應該從哪裡開始重構遺留系統? 前面已經選定目標系統使用的技術,建立一致的開發環境,也定義框架、共用元件與程式碼規範。接下來要開始實作功能,但遺留系統通常包含多條...
如何從遺留程式碼找出功能規則? 前一章已經選出一項代表性的完整功能,準備用它驗證目標系統的架構與共用基礎。開始實作前,還需要把這項功能在遺留系統中的實際行為轉換...
如何驗證功能是否正確? 上一章已經把遺留系統的執行路徑、功能規則與例外情況整理成可實作的規格。目標系統完成對應功能後,還需要確認實際結果是否符合這些規格。程式可...
如何拆分大型流程? 前一章已經透過固定案例確認目標功能的輸入、輸出、狀態變化與失敗結果。功能行為受到測試保護後,就能開始整理目標程式的內部結構,避免後續功能逐步...
甚麼時候需要撰寫註解? 前一章已經透過函式拆分、專用資料結構與明確命名,讓程式本身表達流程與功能意圖。結構清楚之後,仍有部分資訊無法直接寫進函式名稱或條件判斷,...
如何找出目標系統需要處理的安全風險? 目標系統已經按照確認過的功能規則重新實作,仍然不能只根據程式可以執行就判斷安全性。相同的輸入方式、保存狀態或相依項目,在不...
如何檢查來源不明的資料型別? 前一章已經找出目標系統的安全邊界與風險情境。其中一項常見問題,是程式在沒有確認內容的情況下,直接使用來自邊界外的資料。只要欄位缺漏...
如何管理系統異常事件? 前一章已經說明如何在資料進入主要處理前檢查內容。不過,資料通過驗證後,仍可能因為目前狀態不允許操作、程式缺陷、執行資源不足或相依項目失敗...