大規模系統重構

經年累月下來，系統通常會顯得老態，具體症狀是 1. 一個貌似非常簡單的功能，開發團隊居然要花很多時間才能把這功能加入系統 2. 辦理促銷活動前，技術人員如臨大敵，尤其是維運團隊。只要有上述這兩個跡象，你基本可以判定，系統需要進廠大修了。這篇文章概略描述大規模系統重構的方法。

別急，想做大規模重構，你還必須先評估兩件事：1. 重構或不重構 2. 開發能力是否足夠。

你必須先評估系統重構所需要的時間是否太長、需要的資源是否太多、對長期的效益是否值得、以及整體風險是否可控。如果不做系統重構，還有沒有其他選擇？例如升級硬體設備、採購新系統、自行開發新系統，同樣評估這些可能選項的時間、資源、效益、風險，才做決定。

在評估重構或不重構的同時，也必須對系統狀態做全面的匯總，尤其是：每一個系統的目標、功能、介面、關聯系統。全面的匯總資訊除了有助於評估重構或不重構，也有助於在決定重構後選擇適合的重構目標。

重構也是一種開發，但這種開發比單純的開發通常更困難，所以你必須評估現階段團隊的開發能力是否流暢。如果你的團隊在單純做開發時就已經搞得磕磕絆絆，那麼還去做重構，無疑會人仰馬翻，這時候，你需要的不是去重構，而是去提升開發流程、熟悉開發語言和框架、凝聚團隊的向心力。也就是說，先「整軍經武」。

如果上述這兩點都明確了，就可以進入「重構循環」，這是一個四階段持續輪迴迭代的過程：第一階段是「選擇目標」，第二階段是「規劃建模」，第三階段是「開發測試」，第四階段是「回顧總結」。第四階段後，回到第一階段，進入下一個循環。一個循環的長度最好控制在一個月到一個季度之間，因為短於一個月做不了有意義的事，而超出一個季度容易失控。

目標的選擇，主要受到三個因素的影響：團隊成員在重構方法的熟悉程度、主管（或業務方）的支持程度、客戶的感受。如果團隊成員對重構方法比較陌生，那麼可選擇比較簡單、風險比較低的目標，例如API介面的重構。這時候真正的目標是：培養做事的方法和團隊的默契。如果主管的支持程度比較低，且團隊已經有方法和默契，可以選擇他關心的問題作為重構的目標，來得到他的支持。如果明確知道有哪些地方重構後，可以提升客戶的感受，也可以選為目標，客戶的讚揚，會輾轉化為主管的支持。

另外，打破系統之間的循環依賴，這也是非常值得做的重構目標，對長期體質的調養是有好處的。如何做到這件事，需要另寫專文。

第二階段是規劃建模，把現在的系統現況分析清楚，對未來的目標建模，接下來設計如何分工完成。規劃建模的部分包括邏輯重構、介面隔離、資料搬遷的具體方法。

第三階段是開發測試，把前面的規劃付諸實現。測試是關鍵，採用灰度發布是有必要的，也就是說，讓新舊同時並行一段時間，比對驗證，逐步切換，以避免不可挽回的錯誤。

最後的階段是回顧總結。每個循環的過程產生的經驗，要保留下來，擴散出去。問題提出來討論，大家一起發想。這是提升個人能力和團隊實力的時刻，千萬不要放棄了這絕佳的機會。還可以把一些經驗教訓變成流程的一部分，甚至累積出一套一套好用的模式、工具庫、框架。

你在變老，系統在變老，團隊在變老，公司也在變老。透過良好的重構，你在回春，系統在回春，團隊在回春，公司也在回春。但回春需要正確的方法，就怕採用的方法錯誤，導致崩壞加速