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

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

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

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

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

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

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

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

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

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

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

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

作者簡介


Advertisement

更多 iThome相關內容