如何來一次說幹就幹的重構 (流程篇)

摘要： 科學的重構流程。

• 原文：如何來一次說幹就幹的重構 (流程篇)
• 做者：逐鹿 IT, 猛猛如玉

Fundebug經受權轉載，版權歸原做者全部。

前言

隨着公司業務的爆炸式的增加，需求規模和用戶規模也迅速地膨脹起來，這樣給系統的三高(高性能、高併發、高可用)以及擴展性、可維護性都帶來了考驗。而舊系統由於早期設計的各類侷限性（如早期參與人員的水平、架構設計的前瞻性、老闆的急性子等等），逐漸知足不了現狀和將來的新需求，暴露出各類問題。開發人員們像是拖着老破車上高速，苦不堪言。（說人話：老系統代碼的坑太深了，開發們填不住了，要麼被坑埋了，要麼棄坑逃跑了…）

那麼這個時候，一般要面臨一個問題：是繼續填坑仍是跑路走人 選擇重構。填坑是不可能的，這輩子都不可能的。而選擇重構是須要壯士斷腕的勇氣，由於重構是一項老大難、一件耗時耗力的事情，且多少會對現有業務開發形成影響，甚至是停滯。所以大多時候得不到產品經理和老闆的支持，他們關心的只有一個：下個需求何時能上！至於其餘的，都是大家研發該操心的。

本身選擇的重構路，跪着也要走完。如何來一次就幹就幹的重構呢？根據互聯網常見項目重構流程，以及個人親身參與的重構項目經歷，梳理大中小型系統的常見重構流程以下：

零：說服業務方

重構不單是研發團隊的事情，更是整個項目團隊的事情。重構能夠提高系統的三高，也能夠優化改善業務流程，知足新的業務訴求等等。重構須要投入大量資源，必需要獲得業務方的支持。一般這個時候須要對他們曉之以理，動之以情，闡述清楚重構的利弊，以及不重構的要害。在獲得他們的支持後，重構的工做便正式開展。

參與人員：技術 Leader

一：樹立重構目標，有的放矢

重構是一項工程，是一場持久戰，它不是一兩個迭代、甚至一兩個月能作好的事情，須要投入大量的人力、物力、時間精力等。那麼在這場曠日持久的戰鬥中，咱們的目標是什麼？是經過更優秀更合理的架構來知足系統三高的需求，仍是想經過重構來提升代碼質量，或者引入新的技術和框架來升級整個系統，抑或經過重構來優化業務流程，實現原來實現不了的需求。有了目標後，才能作到有的放矢。

參與人員：技術 Leader，架構師

二：肯定重構的範圍，並對重構做出預測

重構一般有如下幾個級別的重構

• 平臺級別重構。針對總體平臺的重構，如阿里早期是 LAMP 架構，後來總體遷移到了 Java 平臺。
• 系統級別重構。針對業務系統的重構，如經過引入微服務架構或者 SOA 架構，分解單體應用。
• 架構級別重構。如經過架構的調整和從新設計，改善原有架構的不合理之處。如經過分層使業務解耦，引入緩存設計提高系統高併發等。
• 業務級別重構。常見爲某些業務需求由於系統設計的不合理性致使沒法知足或有缺陷知足，須要經過業務系統的重構調整或數據庫的重構來解決。
• 模塊/代碼級別重構。這是最多見的重構。一般指使用設計模式、封裝繼承、優化拆解代碼，使得代碼的結構更良好，運行效率更高。

肯定此次重構是屬於什麼級別，肯定重構的總體範圍的大小，肯定重構的技術選型，進而對重構工做進行科學的評測和預估。好比須要投入哪些成本，須要投入的人力和時間是多少，在重構的過程當中可否支撐正常業務需求等等。在有了這些預測後，也對業務方有個交代，尤爲是當他們追在後面問何時能上新需求。

參與人員：技術 Leader，架構師，研發人員

三：舊系統的熟悉和業務梳理

重構不是和舊系統說散就散，而是要不斷和舊系統戰鬥的過程。知己知彼，百戰不殆。重構不只須要清楚新系統的目標和將來，更須要對舊系統很是熟悉(尤爲是坑)。此時須要參與重構的人員(尤爲是參與舊系統的人員)來對舊系統業務和系統進行梳理，對原有資料信息進行收益和整理的工做，對舊系統的關鍵代碼和數據庫設計進行 Review 等等。

如下是重構舊系統前須要準備的常見工做：

• 舊系統資料和信息的收集，包含且不限於系統相關的設計文檔和技術文檔等文檔資料，架構圖、UML 圖，數據庫設計 ER 圖等圖形化資料
• 業務線和業務流程的梳理，整理業務線上的各大項目、業務流程，並輸出爲文檔
• 舊系統關鍵代碼的 Review

有相關疑難點及時與相關與業務線上的人員溝通，將問題解決在」襁褓」中。

參與人員：技術 Leader，架構師，研發人員

四：數據庫重構

若是在重構中須要涉及數據庫的重構，數據庫的重構通常是最早開始的一步。系統須要重構的直接緣由，也大多和數據庫有關。在數據庫重構時，咱們清楚舊系統中數據庫的各類設計缺陷和使用障礙，那麼就能夠對症下藥，如經過三大範式或反範式來設計表，是否須要分庫分表等等。

參與人員：DBA，架構師

五：後臺系統重構

後臺系統重構前，必須須要依照前文所述的一些設計和技術文檔。這些文檔輸出後並經討論成型後，架構師進行系統架構設計，後臺開發人員進行具體編碼工做。一般這個過程是耗時最長的，也是很是重要的一環。後臺的架構設計水平，決定着系統重構的水平，業務代碼的質量，決定着系統重構的質量。

由於這個過程比較漫長，且成果沒法立竿見影。因此一般採用敏捷開發的模式，經過迭代的方式來進行後臺系統重構。迭代的方式有幾個好處：

• 須要將整個重構過程進行有效規劃和量化，作到成竹在胸
• 每一個階段能有可見的成果，確保團隊在長時間的重構過程當中不陷於泥潭
• 對已重構好的部分能夠及時進行聯調測試或觀察，不斷在迭代中總結、在總結中迭代

另外在後臺系統重構時，也須要有明確量化的目標和標準，好比各系統和業務模塊支持多少 QPS，接口響應時間多長時間等，這樣團隊才能在重構的過程當中不至於爲了重構而重構。

在重構過程當中，按期進行 Code Review，及時發現重構的問題和質量的問題，避免出現破窗效應，引入拙劣的設計或垃圾代碼，進而破壞整個系統。

參與人員：技術 Leader，架構師，研發人員

六：數據遷移與檢查

若是涉及數據庫重構時，在新的數據庫設計好後，就會有面臨數據遷移的問題。通常分爲全量遷移和增量遷移，全量遷移是將舊系統的數據一次性遷移到新的數據庫中，增量遷移是在實行全量遷移後舊系統新產生的數據遷移到新系統上來，增量遷移一直到舊系統下線再也不產生新數據後。一般遷移都是經過編寫腳本或程序來實現，拒絕人工操做。

遷移後天然須要對比新舊系統的數據，一樣能夠經過腳本或程序來進行對比，查缺補漏，定位分析。

參與人員：DBA，研發人員

七：系統檢查、聯調與測試

在後臺系統重構到必定程度時，一樣也須要編寫腳本和程序來對新舊系統的業務接口進行檢查，及時發現重構中的問題，必要時候進行架構調整和數據庫調整。固然，在重構時，開發人員能提升單元測試覆蓋率固然是更好不過。當各系統和模塊的依賴解決的差很少時，能夠開始聯調工做。

固然最後還須要系統性的測試，如功能性測試、穩定性測試、性能測試，本地測試、模擬線上環境測試等。測試中發現的問題經驗證修復後，達到上線的標準，便可灰度上線。

參與人員：架構師，研發人員，測試人員

八：灰度發佈與觀察

萬里長征已經走到最後，也到了最緊要的關頭。灰度發佈時，只接入一小部分流量，並及時跟蹤和分析線上的 log 與監控告警，一有問題及時解決。當新系統趨於穩定時，能夠逐漸加大灰度發佈的範圍和接入的流量，同時繼續跟蹤線上 log 與監控告警。

參與人員：運維人員，測試人員，研發人員

九：系統切換

在系統切換時，須要提早制訂系統切換方案，包含相應的規劃與流程，甚至是應急預案與回滾方案，避免走一步看一步。切換完成後，新系統徹底替換舊系統，舊系統下線，完成重構。

參與人員：運維人員，測試人員

結語

經過上述幾個步驟後，咱們成功對系統進行重構。

重構是一項大工程，但經歷重構後的系統也並不是天衣無縫。重構不是終點，更像是起點。

關於Fundebug

Fundebug專一於JavaScript、微信小程序、微信小遊戲、支付寶小程序、React Native、Node.js和Java線上應用實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了10億+錯誤事件，付費客戶有Google、360、金山軟件、百姓網等衆多品牌企業。歡迎你們免費試用！