處理舊有系統¶
舊有系統（Legacy system）對許多開發者來說，是場惡夢。 它通常有幾個特點：
- 這個系統從早期便存在；
- 和很多既有的系統有隱晦的聯繫；
- 是個在商務邏輯中不重要的系統；
- 長期穩定的運行，沒有發生過什麼會導致多系統崩潰的情況。
由於他的穩定，導致沒必要去改，由於他的盤根錯節，導致要去改很困難。 進而引起它變成舊有系統：使用舊的運行系統、舊的語言版本、舊的相依套件等等。
在處理舊有系統時，通常會有五個方法。 這些方法並不僅僅只是獨立的方法，更有甚者，它們可能是一系列處理舊有系統的步驟：
擱置¶
一個最省力的方法，擱置（avoidance）。
你評估過改變帶來的成本和風險，於是決定維持現狀是最好的辦法。 通常討論過程中會伴隨著未來可能可行的方向，只是當下欠缺某些條件或環境。
包裝¶
透過應用程式設計介面（Application Programming Interface, API） 你可以把舊有系統包裝（encapsulation）起來。
透過新的語言、套件、服務包裝舊有系統，這種手法稱為 Strangler Pattern – Martin Fowler 或 Encasement Strategy – Dr. Robert L. Read。 在這過程中，你既能確保服務不會有相容性問題，也能增加一點可以控制的面積。
擴充¶
既然要改變很難，那我就僅僅擴充（augmentation）他的功能，讓盡可能優化而不去異動商務邏輯。
這種手法通常會和包裝併行使用。
替換、撤除¶
這種手法很直觀，替換（replacement）部分功能或者直接撤除（retirement）舊有系統。
先從簡單或急迫的功能慢慢改，做一些部分的替換。 或者直接從頭重寫，並把線上的輸入輸出都保留下來，然後驗證新的系統並不會有任何破壞。
託管¶
舊有系統之所以難以改動，有很大一部份的原因在於它和其他系統的隱晦關係。
當你調整完舊有系統或直接撤除，卻突然有一個團隊告訴你：「抱歉我的系統因為你的改動壞了。」 既然改動舊有系統是共識，並且已經開始執行了，在其他團隊因為時程或其他專案關係無法配合改動時 （即使你已經盡可能滿足並相容大部分情境了）， 你可以把舊有系統的管理權（ownership）託管（custodian）給另一個需要它的團隊。
方法的整合¶
上面提到的這些方法其實也可以整合成一整套的改動步驟：
- 我們意識到舊有系統的改動要付出大量精力，於是 擱置。
- 後來決議還是要改，於是你先把舊有系統 包裝 起來。
- 並且配合一些新的規範或要求來 擴增，例如使用新版的套件來解決 CVE。
- 逐漸 替換 部分功能，並使用線上資料確保正確性，最後完整 撤除 舊的實作。
- 當舊有系統對某個團隊仍是必要的，就把保管權 託管 於它。
總結¶
舊有系統是需要跨單位之間的努力，在處理的過程很有可能是曠日費時的。 對他抱有耐心並持續一小段一小段的解決，這便是處理舊有系統的心法。