遺留系統重構的三個原則

一箇中大型的系統因爲業務快速迭代，某些模塊不斷由於項目的排期，引入臨時方案，而臨時方案最後又變成了最終方案。 

這種技術債務不斷積累，致使模塊逐步變得僵化，對業務的支撐只能依靠研發團隊不斷加班，在原有的系統上打補丁來支持，維護成本很高，擴展性不強。 

這個過程不斷持續，整個系統處處都是坑，到最後，只有用一個新的系統來替代，把老系統下線。

這種粗粒度的重構，一般都涉及比較廣的業務範疇，若是考慮不全面，實施很差，會對整個系統形成災難性的後果。

 

這兩年在部門進行了幾回核心子系統的重構，有一些我的理解的重構原則，簡單總結一下。

首先，是對遺留系統的功能作減法，從業務層面選擇最基礎和最核心的功能優先完成。

一個軟件系統，20%的功能就能夠知足業務方80%的功能，選擇這20%的功能首先進行重構，能夠在較短的時間構建一個可使用的版本上線；等新系統上線以後，按照重要程度從剩下的80%的功能點選擇一部分迭代開發，對於原來一些不經常使用的輔助性功能能夠直接丟棄，避免沒必要要的複雜度。

商業系統一般業務流程比較重，而且和整個組織架構的角色權限結合在一塊兒，在重構的過程當中，也能夠和業務方一塊兒對流程進行精簡，進一步下降系統的複雜度。

此外，若是核心領域模型存在多個版本，在重構的時候要在系統內部完成統一，從根上解決基礎數據結構多樣性帶來的業務複雜性。

好比對於電商系統，商品是最基礎的領域模型，若是系統內部存在多個版本，業務層須要根據不一樣的版本進行不一樣的處理，而這些處理的業務邏輯，可能散落在系統的各個角落，業務代碼copy&paste，缺乏統一的處理模式，if-else滿天飛。

對於這種狀況，先要從邏輯層面設計統一的商品模型，另外從物理層面設計數據遷移方案，保證新系統再也不出現這種狀況。

 

其次，新系統對遺留系統的替代，是一個相似灰度發佈的過程，要設計可行的並行方案，從而下降由於新系統不穩定對業務帶來的影響。

新系統是爲了解決遺留系統擴展性和可維護性的問題，從總體架構設計角度進行的優化升級，即便是通過充分測試也沒法保證上線以後不會出現問題，尤爲是在開發節奏快、項目排期緊的狀況下。

若是新系統上線後立刻下線老系統，由於bug、性能、交互設計等等致使用戶滿意度降低，這將給新系統的開發團隊帶來很是大的壓力，一方面要快速處理新系統的問題，另一方面還要開發遺留系統的功能點，這對系統的穩定性帶來極大的風險。

規避這種風險的方法就是在項目開始的時候就思考如何引入小流量的方案，逐步引導用戶遷移到新系統。

 

第三，要充分考慮對周邊依賴系統的影響，在服務層進行向後兼容設計。

服務層是由一系列的API構成，在重構的時候，一般的思路是設計新版本的API集合，根據新系統的領域模型對輸入&輸出進行從新設計，同時保留原來的API，這種方案適用於調用方比較少的狀況。 

若是調用方不少，每一個調用方都須要配合進行重構，上面的方法，不論是從項目推進仍是風險控制都存在問題。

這種狀況，能夠考慮引入一個服務分發層，保證API接口不變的狀況，根據API調用的上下文，把請求分發給遺留系統和新系統分別處理；分發層聚合調用結果，從而達到對調用方透明的目的。

當遺留系統徹底下線以後，在新系統裏去掉分發層，完成整個服務層的遷移。

 

新系統重構完成以後，爲了不通過一段時間的演進，蛻化爲另一個遺留系統，須要在功能迭代過程，處理好質量要求和項目進度的矛盾，這是另一個值得深刻討論的話題。