重構遺留系統需要做哪些事？

全面重構遺留系統涵蓋從既有系統移轉至目標系統的所有必要工作。建立新專案、遷移既有程式碼與替換正式環境只完成其中一部分，重構工作還可能需要處理既有功能、歷史資料、相依項目、執行環境、部署流程，以及只有實際操作或維護人員才知道的操作規則。

因此，本系列所稱的「全面重構」，可以視為一段從既有系統移動至目標系統的遷移過程。這段過程大致會經歷以下階段：

1. 確認需求、問題與重構目標。
2. 分析既有系統的功能、資料與相依關係。
3. 設計目標系統，以及從既有系統遷移至目標系統的方式。
4. 逐步實作功能、建立測試，並且視需要轉換資料。
5. 驗證目標系統是否符合需求與既有行為。
6. 部署目標系統，執行正式切換及必要的版本還原。
7. 監控目標系統的運作狀況，最後讓既有系統安全退場。

這些階段雖然有先後關係，卻不一定只執行一次。例如，分析既有系統時可能發現原本沒有記錄的功能、測試時可能發現目前的資料表達方式無法呈現某項系統規則、部署與切換演練也可能要求重新調整遷移方式。專案可以反覆修正，但每一次調整都要有依據與記錄，並且確認風險仍在可接受的範圍內。

確認需求與重構目標

重構前必須先回答「這次專案要完成哪些成果」。如果沒有明確目標，重構工作很容易同時納入既有功能重作與新需求，最後無法判斷時程延誤是來自技術問題，還是專案範圍持續擴大。需求確認需要釐清：

• 哪些既有功能必須保留，外部行為是否必須完全一致？
• 哪些功能可以調整、合併或捨棄？
• 是否有核准的新功能需要一併啟用？
• 效能、安全性、可用性與法規等非功能需求為何？
• 誰可以決定需求取捨，誰負責接受最終成果？
• 哪些可量測的條件代表這次重構成功？

這個階段應該將「維持既有行為的重構」與「改變外部行為的需求變更」分開管理。兩者可以在同一個專案中進行，但必須有不同的驗收依據。否則，當既有系統與目標系統出現差異時，將無法判斷那是預期變更，還是重構造成的錯誤。

分析既有系統的功能、資料與相依關係

需求說明目標系統應該提供哪些功能，既有系統分析則用來找出相關功能目前如何運作。這項工作視情況可能需要閱讀程式碼，也可以使用可取得的文件、執行紀錄、既有測試或實際操作結果交叉確認。缺少相關資料時，應該記錄限制，並且在可行範圍內透過實際操作或建立測試取得分析所需資訊。分析的目標是取得足以設計、實作、驗證與切換系統的資訊。

每套系統的構成不同，分析工作應該依照實際情況處理下列事項：

1. 確認系統有哪些功能、功能目的、如何觸發，以及接收和產生哪些內容。如果功能目的與預期結果已經明確，可以不閱讀既有程式碼，改用新的方式實作。
2. 確認功能的資料來源、資料格式、資料處理方式與輸出格式。
3. 視需要從功能入口閱讀相關程式碼，追查主要處理流程、資料變化與相依關係。
4. 記錄各項功能使用的系統規則、輸入限制與例外處理，並且標示需要保留或經過核准才能調整的行為。
5. 列出重構後仍需保留的資料、檔案、執行紀錄與系統狀態。
6. 如果既有系統會與其他程式互動，記錄互動方式、輸入輸出與中斷影響。
7. 記錄系統的執行設定、啟動方式、部署步驟與人工處理程序。
8. 確認正式環境中會影響系統行為的資料格式、操作順序與特殊條件。

分析結果應該區分為「已確認的事實」、「根據現有資料推斷的規則」與「仍待確認的問題」。無法確認的內容不能直接成為目標系統規格，應該記錄疑問及影響，並且依照可取得的資訊繼續驗證。

這個階段可以先建立功能清單、資料流向、相依關係圖、已知風險與待確認問題。這些成果會隨著理解增加而更新，並且作為後續設計與驗收的依據。

設計目標系統與遷移策略

理解需求與既有系統後，才能設計目標系統。設計內容可能包含程式結構、資料表達方式、組成項目的責任、輸入輸出邊界、安全限制、記錄方式、建置與部署流程，以及執行環境。目標系統的架構應該依照需求與已確認的問題設計，不應加入沒有明確用途的分層或組成項目。

設計目標系統時，也要規劃如何完成遷移。專案可以在指定時間完成整體切換，也可以按照功能、資料或使用範圍分階段切換。採用哪一種方式，會影響實作順序、資料或狀態同步方式、測試範圍與還原難度。

遷移策略至少要回答下列問題：

• 如果有資料或保存狀態需要移轉，要轉換成甚麼形式？
• 如果既有系統與目標系統會同時使用或修改相同內容，應該以哪一套系統為準？
• 哪些功能可以分開切換，哪些功能必須一起切換？
• 遷移失敗時，要如何停止、重新執行或復原？
• 如何驗證切換後的功能、資料與系統狀態正確？

目標設計除了要能解決既有問題，也要能被實作、測試、部署、操作與維護。遷移策略則應該證明專案能安全抵達這個目標。

逐步實作功能，並且視需要遷移資料

全面重構的範圍通常較大。如果等到所有功能完成後才第一次整合，許多問題會集中在專案後期才出現。實作目標系統時，可以先選擇範圍明確且能走完輸入、處理、輸出與驗證流程的功能，再按照相依關係擴大實作範圍。

功能實作應該以已確認的需求與既有系統行為為依據。既有程式碼要保留、局部調整、重新實作或逐行改寫，應該視實際情況決定。如果存在責任混合、限制不再適用或無法支援目標設計的部分，可能需要重新設計。採用逐行改寫時，仍要避免將不再需要的限制與已知問題一併帶入目標系統。無論採用哪一種方式，都應該保留經過確認的行為與系統規則，並且將既有實作方式作為分析參考。

如果資料或保存狀態需要遷移，相關工具應該能在測試環境中重複執行，並且記錄每次執行的來源、轉換結果、失敗原因與完成時間。驗證方式應該依照資料特性比較遷移前後的數量、關聯、內容摘要或其他關鍵值，避免內容雖然完成寫入，實際意義卻已改變。

每完成一段功能或一批遷移工作，就應該執行對應測試。這能在變更範圍仍然明確時找出問題，也能使用實際結果調整後續工作。

透過測試確認既有系統與目標系統行為一致

目標系統可以採用不同的技術與程式結構，但必須保留的功能仍要符合既有規格。測試需要隨著實作持續進行，確認相同的有效輸入會產生符合規格的結果，已核准的差異則符合新的驗收條件。

測試依據可以來自需求、操作情境、既有系統的執行結果、歷史資料與已知錯誤案例。除了正常流程，也要依照系統特性涵蓋無效輸入、邊界值、相依項目失效、特殊資料與大量資料等情境。

重構過程可能需要下列層次的測試：

• 單元測試（Unit Testing）：驗證獨立規則與資料轉換。
• 整合測試（Integration Testing）：驗證組成項目與相依項目能否正確協作。
• 端對端測試（End-to-End Testing）：驗證從觸發條件到輸出結果的完整流程。
• 效能與安全性測試：確認系統符合已定義的非功能需求。

既有系統與目標系統的結果不同時，應該確認差異屬於已核准的需求變更、既有系統的已知錯誤，或目標系統的實作缺陷，再依照結論修正規格、程式或測試，並且留下決策紀錄。

規劃部署、切換與還原

功能、資料與非功能需求通過測試後，還要確認目標系統能在正式環境中完成部署與切換。依照系統實際情況，切換可能涉及停止既有系統接收新輸入、保留可復原的系統版本、轉換最後一批資料或狀態、部署目標系統、調整系統進入方式，以及驗證關鍵功能。

這些工作應該整理成按照順序執行的切換計畫，並且在接近正式環境的條件下演練。演練除了確認每個步驟可以執行，也要記錄所需時間與結果，判斷是否符合允許的中斷範圍。

還原（Rollback）計畫應該明確定義：

• 出現哪些情況時必須停止切換或執行還原？
• 由誰判斷是否停止切換？
• 系統程式、設定、資料與執行狀態要如何復原？
• 目標系統已接收或產生的新內容要如何處理？
• 在甚麼時限內仍能安全切換回既有系統？

只準備前一版程式，無法處理切換後新增或變更的資料。還原計畫需要同時考慮程式、設定、資料與外部相依，才能維持系統的一致性與完整性。

觀察目標系統，並且讓既有系統退場

目標系統開始實際運作後，需要進入穩定觀察期。觀察內容應該依照系統特性涵蓋執行狀態、錯誤情形、處理時間、輸出差異、自動執行結果與實際操作回報。

觀察項目、可接受範圍與處理方式應該在正式切換前決定。如果結果超出範圍，負責人需要按照事前定義的條件判斷要修正目標系統、限制部分功能，或切換回既有系統。

既有系統退場前，應該確認：

• 目標系統已在約定期間內穩定運作。
• 既有系統不再接收新輸入或提供仍被需要的功能。
• 必要的資料、紀錄、設定與操作知識已完成移轉或保存。
• 其他程式、人工流程已改用目標系統，或已確認不再需要原有互動方式。
• 備份、文件與仍需保留的執行成品已有保存期限與負責人。

完成這些確認後，才能按照退場清單停用既有系統與不再需要的相依項目，並且保留必要的資料、文件及復原依據。

區分既有系統、目標系統與遷移工具的責任

全面重構期間，既有系統可能持續運作，目標系統則逐步完成實作與驗證。如果資料或保存狀態需要移轉，還可能需要獨立的遷移工具。三者的責任與可修改範圍應該清楚區分。

不同階段也要指定主要資料或系統狀態的來源。例如，開發期間通常仍以既有系統為準，切換演練可以使用既有資料或系統狀態的受控副本，正式切換後則由目標系統接手。這項關係如果沒有定義，兩套系統可能同時接受修改，卻缺少可靠的合併方式。

明確分配重構過程的責任

遺留系統的知識可能分散在操作、需求、開發、測試與維護等工作中。專案應該依照實際規模分配下列責任。同一人可以承擔多個角色，一項責任也可以由多人共同處理。

責任非分重點是每項工作與決策都有明確負責人。需求取捨、風險接受與最終驗收也要由適當角色決定，不能在實作過程中自行假設。

保存各階段的可驗證成果

每個階段都需要留下足以說明決策與結果的成果，讓後續工作可以確認依據。成果可以集中在同一份文件或管理工具中，不必為每一項內容建立獨立檔案。

成果形式可以依照專案規模調整，但重要決策、負責人、驗證結果與尚未解除的風險都要保留。這些內容也需要隨需求、設計與實作變更同步更新。

使用里程碑與決策關卡控制風險

里程碑（Milestone）代表一項可驗證成果已經完成；決策關卡（Decision Gate）則是用於確認各項關卡要求的成果與驗證紀錄是否完整，並且確認尚未解決的風險是否在可接受範圍內。

全面重構可以依照實際情況設定下列關卡：

1. 範圍確認：需求決策者已核准功能範圍、優先順序與驗收條件。
2. 分析完成：關鍵功能、資料、相依關係與主要風險已有明確的分析結果，足以支持後續設計。
3. 設計核准：目標系統與遷移策略可以實作、測試、部署、還原及維護。
4. 切換準備完成：功能、資料與非功能需求已通過必要測試，切換與還原程序已完成演練。
5. 正式切換核准：執行時間、備份、觀察方式、負責人與停止條件均已確認。
6. 既有系統退場核准：目標系統已穩定運作，既有系統的資料與相依項目均已妥善處理。

如果關卡未通過，應該補齊該關卡尚未完成的成果與驗證紀錄、降低風險或調整範圍後，再重新判斷。預先定義停止條件與決策責任，可以避免在時程壓力下忽略尚未處理的問題。

重點整理

• 全面重構涵蓋需求確認、既有系統分析、目標系統設計與實作、必要的資料遷移、測試、部署切換、穩定觀察及既有系統退場。
• 需求確認需要區分維持既有行為的重構與改變外部行為的需求變更，並且分別設定驗收依據。
• 既有系統分析應該依照現有情況選擇資訊來源，可能需要閱讀程式碼，也可以使用文件、執行紀錄、既有測試或實際操作結果確認系統行為；分析結果要區分已確認的事實、推斷的規則與待確認問題。
• 目標系統設計需要考慮實作、測試、部署、操作與維護；遷移策略則要確認資料或狀態的轉換、切換範圍、失敗處理與驗證方式。
• 既有程式碼要保留、局部調整、重新實作或逐行改寫，應該視實際情況決定；實作期間要持續測試，並且在需要遷移資料或狀態時記錄與驗證轉換結果。
• 測試需要確認必須保留的功能符合既有規格，已核准的差異符合新的驗收條件；結果不同時，應該確認差異原因，再修正規格、程式或測試。
• 切換計畫應該在接近正式環境的條件下演練，還原計畫要同時考慮程式、設定、資料與外部相依；正式切換後需要按照事前定義的條件觀察目標系統，確認既有系統可以退場。
• 既有系統、目標系統與遷移工具具有不同責任，各階段也要指定主要資料或系統狀態的來源。
• 重構工作應該依照專案實際情況分配操作、需求決策、開發、測試與維護責任，並且保存各階段的決策與驗證成果。
• 里程碑與決策關卡應該使用可驗證的完成條件與風險狀態，確認各項關卡是否通過；未通過時，應該先補齊該關卡尚未完成的成果與驗證紀錄、降低風險或調整範圍。