1、 系統重構的最佳實踐EGONetworks 微信號 egonetworks功能介紹 EGO是極客邦科技旗下高端技術人聚集和交流的組織，以CTO、技術VP等技術領導者為服務對象，采用實名付費會員制，嚴格審核會員資格，旨在組建全球最具影響力的技術領導者社交網絡，線上線下相結合，聯結杰出的技術領導者學習和成長。我們日常工作中，系統重構應該是最讓人頭疼的了，無論是錯綜復雜還是簡單的系統，在發展的過程中都會經歷重構，系統重構也是任何技術團隊無法回避的問題，在我服務的多家公司，幾乎每家公司都經歷了一次甚至多次系統的重構，本文就我在多年的重構工作中總結出來的幾點建議分享給各位朋友，希望能夠給朋友們帶來幫助。

2、重構確定并且聚焦目標首先我相信我們大家都確信，系統重構會有巨大的成本投入，業務可能需要暫緩、新系統引入的問題（ BUG ）會帶來業務的不穩定，存在研發人員投入開銷還有各種隱性成本等等。我們服務的商業公司，獲取利潤是最終目的，投入成本做一個項目肯定要獲得收益。重構的目標一定要能夠獲得更大的提升，無論是業務流程、系統性能或是其他方面，如果僅僅一個很小的改善，完全沒必要大費周章。因此重構之前權衡好成本，重構是否能夠獲得良好的收益？無論如何進行系統重構都是一次傷筋動骨的過程，是涅槃重生還是飛蛾撲火，完全取決我們項目執行的過程中是否明確了目標，且一直聚焦于目標的實現。保持目標的聚集是能否取得良好結果的必

3、要條件。如果我們僅僅確立了目標，但沒有聚集于目標，反而在多個非重要的節點投入較大資源，必然會導致我們對目標的投入降低。工作中的原始資本投入都是 8 個小時，這就需要我們明確目標聚焦目標，把有限的資源投入到最重要的事情中，才能獲得既定目標的良好結果。重構要有可量化的指標團隊確認了重構的目標之后，下一步要將目標量化，確定好目標之后就能夠確認邊界，圍繞在邊界內將需要實現的事項一一羅列出來，盡可能對每個實現制定可以用數據清晰表現出來的指標，比如用戶操作的響應時間縮短到 100 毫秒、單元測試的覆蓋率達到 80% 、發現問題時長降低到 30 分鐘以內等等。有了明確的數據指標我們才能評估最終是否獲得了良好

4、收益，這些目標必須要在重構團隊，包括產品、研發、測試甚至包括業務方在內達成一致，團隊的目標需要清晰明了，防止出現過度或是不達標是最終不能獲得良好收益。重構要有更好的質量既然決定了要對系統進行一次重構，那么我們肯定要做到的就是要比之前做的更好，如果之前接口響應時間在 100 毫秒，而經過重構之后反而到了 200 毫秒以上，那么大家辛苦付出的努力是不是也更加不值得。而進行重構往往是一件十分引人注目的事情，一個微小的問題反而容易在眾人注目下變得非常嚴重的問題。為了減少引起不必要的麻煩，重構團隊就更加要注重各個方面的問題，無論是系統性能、用戶體驗還是 BUG 數量等。重構之前要和業務方溝通技術團隊進行

5、系統重構的工作的時候往往忽略掉了業務方，認為這是技術團隊內部的事情，不需要知會業務方，這個想法是非常錯誤的，進行重構的目標就是為了改善改進業務流程，而不去和業務方提前溝通進行閉門造車，最后的結果很可能和進行重構的初衷背道而馳。進行系統重構首先我們必須了解現有系統的業務需求，是否有待改進的業務需求點，是否有新的業務訴求等，這些需求往往會影響到我們重構的進度和目標，甚至出現南轅北撤的事情。技術團隊和業務方往往對待問題的出發角度不同，思考問題的方式也不同，在進行重構之前和業務方溝通獲得業務方的支持，往往能夠事半功倍。例如，我的團隊在進行一塊業務系統重構的時候進入到了系統切換的試運行的階段，由于拿出的

6、方案給到業務方無法被業務方接受，業務方提出的解決方案我們還需要進行再次開發，對整個項目進度影響了足足一個月時間之多。吸取教訓的我們在進行下一個項目的時候提前和業務方進行了溝通，業務方從他們的角度給予了很多的意見和建議以及業務未來的發展方向的指引，我們發現這些建議和意見幫助我們更好理解業務的同時也大大的降低了我們工作量，減少了我們很多冗余的設計。重構應該用迭代的方式參與過重構項目的朋友都知道，重構項目往往是個時間跨度很長的工作，少則一兩個月多則一年半載都有，如果不將整個重構進行合理拆分，而是采用全部開發完成，再進行系統切換的方式會對整個重構引入很大的風險。首先長時間的時間跨度內業務會進行持續變更

7、，其次團隊面臨長時間沒有結果輸出面臨來自各個方面的壓力，還有系統問題持續累積，這種蒙頭狂奔的方式往往造成了項目失敗或是目標便宜。而采用迭代方式進行重構，可以以更小的顆粒度持續交付工作成果，交付 - 試用 - 反饋 - 調整，持續有交付，持續有反饋，持續調整能夠保證團隊的目標不會偏移，形成一個正向循環，保證最后的重構目標。重構要清晰了解舊系統知己知彼，百戰不殆，系統重構是一個與舊系統對抗的過程，不對舊系統的弄的清清楚楚怎么能夠比舊系統做的更好呢？其實了解現有系統是一個學習的過程，如果有舊系統的開發人員還在公司，那么就事半功倍了，舊系統的開發同學幫忙給做次分享，省去了我們重構團隊很多的工作，比直接

8、去讀代碼更能清晰明了的了解到舊系統的相關知識，以及有哪些需求點和應該注意的問題等等，通過學習和了解舊系統設定目標基準值避免引入老舊問題，也是避免重蹈覆轍的一個好辦法。重構要提前規劃系統切換方案不知道朋友有沒有遇到過，重構完系統發現，如果進行新舊系統的切換是個難題。我們以前遇到過由于沒有提前做好規劃和切換步驟，導致最后臨時抱佛腳，開始使用各種奇葩辦法做系統切換，有的還需要增加額外工作量，甚至各種辦法的刷臉求人，總之這不是一個很好的體驗。系統切換往往是在重構中被我們忽略的一個步驟，但是這是非常重要的一個環節，在做最初的計劃就應該考慮到如何進行系統切換，一個設計好的切換方案也應該貫穿重構始終，避免因

9、為切換方案引起服務不可用或是引入系統 BUG 。尤其是前期整個團隊付出巨大努力取得了一定成果的時候，在最后一步切換的時候出現問題，對團隊是個非常大的打擊，也使得業務方對團隊失去信心，帶來很不必要的麻煩。重構高度重視系統數據一次系統重構大多數情況下會涉及到數據結構的修改，對數據結構進行修改必然引入很大的風險，尤其在一些老舊的業務系統重構精簡，業務去掉冗余數據的時候，往往需要將老數據的業務數據重新寫入到新系統的數據庫。重構的目標是為了比舊系統更好，無論是性能還是業務方面，如果我們對數據的操作導致外部依賴舊系統的業務無法正常運行，那將是影響 SLA 指標的問題。說到系統數據有些同學可能僅僅關注的是業

10、務數據，其實數據也包含了系統運行所產生的日志數據，無論新舊系統的日志數據，都是很重要的，如果因為重構影響到數據的讀取、處理、分析，則是得不償失的事情。重構要采用成熟的技術選型技術選型是重構工作的基石，選擇一套成熟穩定的技術方案是重構項目完成的必要條件。有些時候我們引入最新版的數據庫雖說會有性能提升但是也會引入一定的不穩定因素，之前我們團隊在使用 MongoDB 的一個新版本的時候，發現主從庫的數據并不能很好的同步，出現過丟失數據的情況，進入社區發現這個版本使用的用戶很多都反饋了這個問題。這時候我們不得不選擇了大多數人共同的一個選擇，降低了一個版本來解決問題，相信此類情況比比皆是。在不是很成熟的

11、方案帶來并不顯著的性能提升，反而還會引入不確定的風險的時候，我們需要權衡利弊得失，重構更是要保證系統的穩定性。技術方案能否有足夠強大的支撐也是我們需要考慮的一個方面，現在我們團隊面對的重構是從單體式架構往微服務轉變，舊系統的版本構建在是 PHP 語言上，新的系統我們由兩個選擇繼續選擇用 PHP 進行重構或是采用公司統一的微服務框架，我們毫不猶豫的選擇了使用公司統一的微服務，這樣做有幾個顯而易見的好處。和公司內部進行交互更加方便快捷；可以直接獲取成熟的經驗；基礎服務有公司級的支持；以上的好處，顯然對我們能否成功重構系統并且獲得足夠的幫助起到了顯著的幫助，反而采用 PHP 進行微服務，公司內部并無成功經驗可以借鑒，業內也并無太多可靠的方案可以進行選擇。一個成熟可靠的的技術方案是我們能否更進一步的保障和基石。重構更加關注重視團隊成員參與過重構的同學都知道重構工作是一項枯燥乏味的工作，往往周期長、復雜度、難度大、牽扯廣、優先級低，而且很有可能是一件費力不討好的工作。開發一個業務方期待的新功能、新模塊往