導讀：我們日常工作中，系統重構應該是最讓人頭疼的了，無論是錯綜複雜還是簡單的系統，在發展的過程中都會經歷重構，系統重構也是任何技術團隊無法迴避的問題，在我服務的多家公司，幾乎每家公司都經歷了一次甚至多次系統的重構，本文就我在多年的重構工作中總結出來的幾點建議分享給各位朋友，希望能夠給朋友們帶來幫助。

高成，現就職於唯品會，曾服務於微博、愛奇藝等公司，主要從事後端系統的開發和設計工作，參與了多個網際網路應用的開發、設計以及重構工作，擁有電商系統、社交平臺等系統的研發和架構設計經驗，現作為唯品會供應鏈核心系統重構專案負責人主持供應鏈核心系統檔期業務的重構工作。

1、重構確定並且聚焦目標

首先我相信我們大家都確信，系統重構會有巨大的成本投入，業務可能需要暫緩、新系統引入的問題（ BUG）會帶來業務的不穩定，存在研發人員投入開銷還有各種隱性成本等等。我們服務的商業公司，獲取利潤是最終目的，投入成本做一個專案肯定要獲得收益。重構的目標一定要能夠獲得更大的提升，無論是業務流程、系統性能或是其他方面，如果僅僅一個很小的改善，完全沒必要大費周章。

因此重構之前權衡好成本，重構是否能夠獲得良好的收益？

無論如何進行系統重構都是一次傷筋動骨的過程，是涅槃重生還是飛蛾撲火，完全取決我們專案執行的過程中是否明確了目標，且一直聚焦於目標的實現。保持目標的聚集是能否取得良好結果的必要條件。

如果我們僅僅確立了目標，但沒有聚集於目標，反而在多個非重要的節點投入較大資源，必然會導致我們對目標的投入降低。工作中的原始資本投入都是 8 個小時，這就需要我們明確目標聚焦目標，把有限的資源投入到最重要的事情中，才能獲得既定目標的良好結果。

2、重構要有可量化的指標

團隊確認了重構的目標之後，下一步要將目標量化，確定好目標之後就能夠確認邊界，圍繞在邊界內將需要實現的事項一一羅列出來，儘可能對每個實現制定可以用資料清晰表現出來的指標，比如使用者操作的響應時間縮短到 100 毫秒、單元測試的覆蓋率達到 80%、發現問題時長降低到 30 分鐘以內等等。

有了明確的資料指標我們才能評估最終是否獲得了良好收益，這些目標必須要在重構團隊，包括產品、研發、測試甚至包括業務方在內達成一致，團隊的目標需要清晰明瞭，防止出現過度或是不達標是最終不能獲得良好收益。

3、重構要有更好的質量

既然決定了要對系統進行一次重構，那麼我們肯定要做到的就是要比之前做的更好，如果之前介面響應時間在 100 毫秒，而經過重構之後反而到了 200 毫秒以上，那麼大家辛苦付出的努力是不是也更加不值得。而進行重構往往是一件十分引人注目的事情，一個微小的問題反而容易在眾人注目下變得非常嚴重的問題。為了減少引起不必要的麻煩，重構團隊就更加要注重各個方面的問題，無論是系統性能、使用者體驗還是 BUG 數量等。

4、重構之前要和業務方溝通

技術團隊進行系統重構的工作的時候往往忽略掉了業務方，認為這是技術團隊內部的事情，不需要知會業務方，這個想法是非常錯誤的，進行重構的目標就是為了改善改進業務流程，而不去和業務方提前溝通進行閉門造車，最後的結果很可能和進行重構的初衷背道而馳。進行系統重構首先我們必須瞭解現有系統的業務需求，是否有待改進的業務需求點，是否有新的業務訴求等，這些需求往往會影響到我們重構的進度和目標，甚至出現南轅北撤的事情。

技術團隊和業務方往往對待問題的出發角度不同，思考問題的方式也不同，在進行重構之前和業務方溝通獲得業務方的支援，往往能夠事半功倍。

例如，我的團隊在進行一塊業務系統重構的時候進入到了系統切換的試執行的階段，由於拿出的方案給到業務方無法被業務方接受，業務方提出的解決方案我們還需要進行再次開發，對整個專案進度影響了足足一個月時間之多。吸取教訓的我們在進行下一個專案的時候提前和業務方進行了溝通，業務方從他們的角度給予了很多的意見和建議以及業務未來的發展方向的指引，我們發現這些建議和意見幫助我們更好理解業務的同時也大大的降低了我們工作量，減少了我們很多冗餘的設計。

5、重構應該用迭代的方式

參與過重構專案的朋友都知道，重構專案往往是個時間跨度很長的工作，少則一兩個月多則一年半載都有，如果不將整個重構進行合理拆分，而是採用全部開發完成，再進行系統切換的方式會對整個重構引入很大的風險。首先長時間的時間跨度內業務會進行持續變更，其次團隊面臨長時間沒有結果輸出面臨來自各個方面的壓力，還有系統問題持續累積，這種矇頭狂奔的方式往往造成了專案失敗或是目標便宜。

而採用迭代方式進行重構，可以以更小的顆粒度持續交付工作成果，交付 - 試用 - 反饋 - 調整，持續有交付，持續有反饋，持續調整能夠保證團隊的目標不會偏移，形成一個正向迴圈，保證最後的重構目標。

6、重構要清晰瞭解舊系統

知己知彼，百戰不殆，系統重構是一個與舊系統對抗的過程，不對舊系統的弄的清清楚楚怎麼能夠比舊系統做的更好呢？其實瞭解現有系統是一個學習的過程，如果有舊系統的開發人員還在公司，那麼就事半功倍了，舊系統的開發同學幫忙給做次分享，省去了我們重構團隊很多的工作，比直接去讀程式碼更能清晰明瞭的瞭解到舊系統的相關知識，以及有哪些需求點和應該注意的問題等等，通過學習和了解舊系統設定目標基準值避免引入老舊問題，也是避免重蹈覆轍的一個好辦法。

7、重構要提前規劃系統切換方案

不知道朋友有沒有遇到過，重構完系統發現，如果進行新舊系統的切換是個難題。我們以前遇到過由於沒有提前做好規劃和切換步驟，導致最後臨時抱佛腳，開始使用各種奇葩辦法做系統切換，有的還需要增加額外工作量，甚至各種辦法的刷臉求人，總之這不是一個很好的體驗。

系統切換往往是在重構中被我們忽略的一個步驟，但是這是非常重要的一個環節，在做最初的計劃就應該考慮到如何進行系統切換，一個設計好的切換方案也應該貫穿重構始終，避免因為切換方案引起服務不可用或是引入系統 BUG。尤其是前期整個團隊付出巨大努力取得了一定成果的時候，在最後一步切換的時候出現問題，對團隊是個非常大的打擊，也使得業務方對團隊失去信心，帶來很不必要的麻煩。

8、重構高度重視系統資料

一次系統重構大多數情況下會涉及到資料結構的修改，對資料結構進行修改必然引入很大的風險，尤其在一些老舊的業務系統重構精簡，業務去掉冗餘資料的時候，往往需要將老資料的業務資料重新寫入到新系統的資料庫。重構的目標是為了比舊系統更好，無論是效能還是業務方面，如果我們對資料的操作導致外部依賴舊系統的業務無法正常執行，那將是影響 SLA 指標的問題。說到系統資料有些同學可能僅僅關注的是業務資料，其實資料也包含了系統執行所產生的日誌資料，無論新舊系統的日誌資料，都是很重要的，如果因為重構影響到資料的讀取、處理、分析，則是得不償失的事情。

9、重構要採用成熟的技術選型

技術選型是重構工作的基石，選擇一套成熟穩定的技術方案是重構專案完成的必要條件。有些時候我們引入最新版的資料庫雖說會有效能提升但是也會引入一定的不穩定因素，之前我們團隊在使用 MongoDB 的一個新版本的時候，發現主從庫的資料並不能很好的同步，出現過丟失資料的情況，進入社群發現這個版本使用的使用者很多都反饋了這個問題，這時候我們不得不選擇了大多數人共同的一個選擇，降低了一個版本來解決問題，相信此類情況比比皆是。在不是很成熟的方案帶來並不顯著的效能提升，反而還會引入不確定的風險的時候，我們需要權衡利弊得失，重構更是要保證系統的穩定性。

技術方案能否有足夠強大的支撐也是我們需要考慮的一個方面，現在我們團隊面對的重構是從單體式架構往微服務轉變，舊系統的版本構建在是 PHP 語言上，新的系統我們由兩個選擇繼續選擇用 PHP 進行重構或是採用公司統一的微服務框架，我們毫不猶豫的選擇了使用公司統一的微服務，這樣做有幾個顯而易見的好處。

1. 和公司內部進行互動更加方便快捷；

2. 可以直接獲取成熟的經驗；

3. 基礎服務有公司級的支援；

以上的好處，顯然對我們能否成功重構系統並且獲得足夠的幫助起到了顯著的幫助，反而採用 PHP 進行微服務，公司內部並無成功經驗可以借鑑，業內也並無太多可靠的方案可以進行選擇。一個成熟可靠的的技術方案是我們能否更進一步的保障和基石。

10、重構更加關注重視團隊成員

參與過重構的同學都知道重構工作是一項枯燥乏味的工作，往往週期長、複雜度、難度大、牽扯廣、優先順序低，而且很有可能是一件費力不討好的工作。開發一個業務方期待的新功能、新模組往往比一場翻天覆地的重構更能引起業務方的重視，也更容易獲取良好結果與反饋，反而不需要承擔大多的壓力。

但是越是面對這樣的情況越是需要加大對團隊的鼓勵增強團隊的信心，消除團隊的疑慮困惑，給予團隊持續的鼓勵，給整個團隊注入正能量，讓團隊保持積極向上的團隊氛圍，即使面對各種困難、問題，也始終對團隊保持信心保持樂觀，讓大家輕鬆愉快的投入到重構工作中，儘量不擔負額外的壓力。

以上內容均為工作中的總結反思，分享給大家，希望以上的這些總結，能夠對大家有所幫助，文章所講述的內容，如有不足之處還望留言批評指出。