遺留系統需要重構哪些部分？

全面重構的範圍涵蓋目標系統接手遺留系統所需的功能、系統規則、輸入輸出、保存狀態、相依項目、執行設定與維護方式。範圍需要保留仍有需求的行為，也要排除不再需要的內容，不能只根據程式碼是否混亂決定。

確認範圍前，需要先回答三個問題：

1. 這次重構要解決哪些已確認的問題？
2. 目標系統需要完成哪些成果？
3. 哪些既有行為需要保留，哪些差異已經獲得核准？

這些答案會形成重構範圍，作為後續分析、設計、實作與驗收的共同依據。

從問題與預期成果決定範圍

相同的技術問題，在不同系統中可能造成不同影響。例如，停止支援的函式庫可能不再提供修正版，使系統無法透過更新函式庫排除已知弱點。如果它只供即將停用的獨立程式使用，而且不影響其他功能或重要資料，這個項目的優先度(Priority)可能較低。是否納入重構範圍，仍要根據問題對功能、資料與維護方式造成的實際影響判斷。

確認問題時，需要留下足以說明影響的資料與紀錄：

• 記錄經常發生錯誤的功能及其影響。
• 找出需要同時修改多處的變更，記錄曾經發生的遺漏或迴歸問題。
• 確認停止支援或無法在目標執行環境使用的相依項目。
• 量測處理時間、執行量或資源使用情形，確認問題發生的條件。
• 列出無法穩定建置、測試、部署或還原的步驟。
• 記錄只存在於特定人員經驗或人工操作中的重要規則。

每個問題都要對應預期成果。像是「系統很慢」缺少驗收標準；「在指定資料量與執行環境中，處理時間需要落在核准範圍內」才是可量測的條件。實際數值仍要根據需求與現況基準決定。

程式碼層次的重構會改善內部結構，同時維持既有的外部行為。目標系統即使採用不同的程式結構或資料處理方式，相同的有效輸入仍需要產生符合既有規格的結果。如果需求決策者核准調整、移除或增加功能，範圍記錄需要標示差異及新的驗收條件。

確認目標系統需要接手的內容

不同遺留系統具有不同構成。下列分類用來協助尋找可能遺漏的項目，不代表每套系統都具有相同內容。

有些重要工作不會直接出現在程式碼中。例如，操作人員可能在匯入檔案前先手動改名，維護人員可能在特定日期調整執行設定，另一套程式也可能依賴遺留系統產生但未正式記錄的檔案。只閱讀主要程式碼，很容易漏掉這些實際流程。

這個階段只確認需要分析與決策的內容。各項功能如何運作、資料如何變化，以及使用哪些相依項目，會在後續章節進一步分析。

將範圍項目分類

確認可能納入的內容後，可以將每個需要決策的行為或項目分成五類，再把判斷結果寫入範圍記錄。

「調整」需要進一步記錄這項差異是修正已確認的錯誤，還是執行核准的需求變更。兩者可以採用不同的驗收依據，不能直接視為重構過程中的實作細節。「待確認」可以保留在範圍記錄中，但不能直接轉成實作規格。

同一項功能如果包含不同的輸入、規則或輸出，需要拆成可獨立判斷的行為後再分類。例如，可以保留計算規則、調整輸入方式、捨棄特定輸出格式，也可以新增執行結果通知。

捨棄功能前，需要確認是否仍有操作人員、其他程式或人工流程使用這項功能，也要處理相關歷史內容、相依項目、替代流程與停止條件。程式碼搜尋不到呼叫來源或執行紀錄沒有資料，都不足以單獨支持捨棄決策。

記錄優先度與範圍邊界

全面重構仍需要安排分析與實作順序。各項目的優先度可以根據下列因素共同判斷：

可以使用高、中、低分級或一致的數值尺度比較各項目的優先度，但評估結果不能取代需求決策。執行頻率低的工作仍可能在失敗時破壞重要資料，因此優先度需要綜合判斷。如何選擇第一個實作項目，會在後續章節進一步說明。

範圍記錄也要列出本次明確不處理的項目。範圍外項目如果仍與目標系統互動，就需要記錄相關輸入輸出、保存狀態與相依關係。例如，另一套程式不在本次修改範圍內，但會讀取遺留系統輸出的檔案，目標系統就需要維持相容格式，或由相關需求決策者核准新的交換方式。

每個範圍項目需要留下目前已知行為、預期結果、分類、納入與排除內容、判斷依據、核准責任及待確認問題。後續分析如果發現隱藏功能，也要記錄發現來源、影響、處理決定與驗收變化，再由指定人員核准範圍變更。

定義範圍完成條件

功能需求（Functional Requirements）描述系統需要完成哪些工作；非功能需求（Non-functional Requirements）則描述完成工作時需要符合的品質與限制。驗收條件（Acceptance Criteria）用來描述可以觀察或測量的結果。每個範圍項目都需要有對應的驗收方式，明確指出完成判定的時機。

「效能要更好」、「系統要安全」或「程式要容易維護」都缺少判斷標準。需要先建立現況基準，再按照實際需求定義目標值、測試條件與可接受範圍。如果目前無法取得基準，應該將缺少的資訊與補充方式列為待確認項目。

退場條件尚未完成時，遺留系統仍可能需要繼續提供部分功能或保留必要內容。此時可以繼續驗證目標系統或限制遺留系統的使用範圍，直到相關功能、資料、相依項目與維護責任都有明確處理方式。

重點整理

• 重構範圍需要根據專案目標、既有問題與預期成果決定，並將需要維持的既有行為與核准的需求變更分開記錄。
• 目標系統需要按照實際情況接手功能、系統規則、輸入輸出、保存狀態、外部互動及執行維護方式，也要確認程式碼以外的實際流程。
• 每個範圍項目需要分為保留、調整、捨棄、新增或待確認，並留下判斷依據與驗收方式。
• 優先度需要綜合執行頻率、影響範圍、修改頻率、錯誤情形、技術風險、維護成本與驗證難度，範圍外項目也要記錄相依關係。
• 重構範圍需要包含功能需求、非功能需求、驗收條件與遺留系統退場條件，讓每個項目都有可觀察的完成標準。