經(jīng)典著作《重構》這本書中有這么一段話：

01 先聊聊這個系統(tǒng)的歷史包袱

我們的廣告引擎在這次重構前大概經(jīng)歷了1年半時間的迭代，初期針對的是搜索場景，業(yè)務單一，流程清晰。

1、業(yè)務場景開始變得復雜，除了搜索廣告，還需要支持信息流推薦以及相似推薦場景。

2、廣告流量開始快速增加，除了滿足功能性需求，還需要兼顧好性能。

1、為了兼容搜索的特殊邏輯，我們需要在其他場景中增加各種 if 判斷來繞過這些邏輯。

2、廣告策略越來越多，累計了幾十個，當框架失去清晰的結構后，有些策略的實現(xiàn)開始變得定制化，缺少層次化的劃分和可插拔式的抽象設計。

轉機出現(xiàn)在 2019 年年底，由于廣告業(yè)務的特殊性，流量開始自然走低，另外產(chǎn)品運營團隊將重心放在了第 2 年的工作規(guī)劃上，因此給了我們非常好的窗口期開始此次重構。

我們將工期定成了 1 個月，最終僅比預期晚上線了一天，雖然出現(xiàn)了兩個線上問題，但是在灰度期都及時發(fā)現(xiàn)和修復了，并沒有造成線上事故。

02 重構前，我們做了哪些準備工作？

這次重構的代碼量很大，3 萬多行，而且是廣告系統(tǒng)最核心的引擎部分。啟動前，我們能預期到下面這些困難：

1、業(yè)務側的阻力：廣告是極其以業(yè)務為導向的，本次重構雖然能帶來長期研發(fā)效率的提升，但是沒法直接提升業(yè)務收益，而且開發(fā)周期不會太短，如何才能得到業(yè)務同學的支持？

▍讓所有人看到痛點

前面提到：隨著業(yè)務迭代，我們廣告引擎的主體框架已經(jīng)變得模糊不清，另外幾十個廣告策略散落在不同的業(yè)務場景中，配置凌亂。

針對這兩個痛點，我們提前1個月啟動了現(xiàn)有業(yè)務的梳理，走讀舊代碼、同時翻閱以前的需求文檔，最終我們將不同場景的核心流程以及廣告策略歸類成了一張清晰的表格。

正是這一張表格，讓技術和產(chǎn)品第一次很清晰地看到了我們引擎部分的全貌，體會到了業(yè)務的復雜度以及當前技術上的瓶頸。

▍明確重構的目標和價值

讓所有人感受到痛點后，我們規(guī)劃了本次重構的兩個核心目標：

1、主體框架的重構：將主流程模塊化，重新定義上下層協(xié)議，確保接口清晰；各層級內(nèi)部也需要做好抽象，具備良好的擴展性。

2、策略靈活可配置：將廣告策略按照業(yè)務意圖進行歸類抽象，策略的執(zhí)行條件動態(tài)可配置，同時策略可任意插拔。

此外，我們將這兩個核心目標完成后可帶來的預期收益進行了細化：

1、技術收益：代碼結構更清晰，更容易理解和維護；可擴展性增強，引擎的開發(fā)效率將進一步提升。

2、業(yè)務收益：策略能做到更細粒度的配置和擴展，對業(yè)務支持更友好；研發(fā)提效后能進一步加快業(yè)務的迭代速度。

▍整體節(jié)奏的把控

整體節(jié)奏的把控也是非常重要的一環(huán)，能讓所有人對這件事情有一個時間上的預期。

首先，我們將工期定成了 1 個月，一方面考慮了業(yè)務側可以接受的最大周期，技術上也希望速戰(zhàn)速決；另一方面，春節(jié)即將來臨，我們必須趕在公司封網(wǎng)前上線，同時預留出1-2周的 buffer 以防意外情況發(fā)生。

03 執(zhí)行過程中有哪些可分享的經(jīng)驗？

1. 高質(zhì)量的技術設計方案

這一點得益于日常的要求，針對開發(fā)周期超過3天的項目我們都會進行技術方案設計，本次重構當然也不例外。

框架部分的整體架構、模塊之間的協(xié)議設計、以及策略的可擴展性設計是本次技術方案的重點，團隊前后討論了不下3次。

在大方案定稿后，團隊進一步對數(shù)據(jù)庫、接口字段、緩存結構、日志埋點等公共部分進行了細化，因為涉及到多人協(xié)作開發(fā)，團隊約定以文檔作為溝通界面，文檔始終保持和代碼同步。

2. 預重構出框架性代碼

這一個 PR 非常關鍵，是我們從技術方案落地到代碼最重要的一步。我們把重構后的包結構、模塊劃分、各層之間的API定義、不同廣告策略的抽象進行了梳理，先忽略實現(xiàn)的細節(jié)。

這樣主體代碼基本成型，能很清楚地描繪出我們理想中的框架。然后，我們組織了多次集中代碼審查，最終形成了統(tǒng)一意見。

這一步能很好地避免過早陷入實現(xiàn)細節(jié)，導致主體框架關注不夠、代碼不穩(wěn)固，后期再返工反而會拖累效率。

3. 頻繁溝通和成對代碼 Review 機制

進入到細節(jié)實現(xiàn)階段后，很重要的一點是：對現(xiàn)有邏輯的理解。引擎代碼經(jīng)過一年半的迭代，歷史上被很多人開發(fā)過，但是本次只有 3 個同學參與重構。

整個過程中，我們遇到任何代碼邏輯不明確的地方，都是反復溝通和求證，不主觀猜想，這一份謹慎其實很關鍵。

另外在代碼審查上，我們按模塊分配了對這塊業(yè)務比較熟悉的同學來負責，成對搭配，機制靈活。

4. 有效的測試方案

重構未動，測試先行。這個原則是《重構》一書中重點強調(diào)的，也是我們本次技術方案討論的重點，我這里單獨拎出來詳細展開下。

首先，我們前期便約定好：不動任何老代碼，完全建新的 package 進行重構。這樣方便比對重構前后的結果，同時進行線上灰度實驗。

測試方案上，以下 4 點值得借鑒：

1、端到端測試：本次重構不涉及功能性的調(diào)整，因此外層API的行為是不會有任何變化的，這樣端到端的測試方法最為有效，這個是研發(fā)和QA測試最主要的手段。

2、冒煙測試：QA同學提供冒煙 Case，由研發(fā)同學進行冒煙，研發(fā)提測前必須保證所有冒煙 Case 執(zhí)行通過。這一點在大部分互聯(lián)網(wǎng)公司都不常見，但是對于大型項目絕對有效。

3、沙箱環(huán)境雙流程驗證：前面提到我們重構前后的代碼都保留了，因此可以通過腳本抓取線上環(huán)境的入?yún)⒆鳛閏ase，然后用自動化的方式對 API 的返回字段進行逐一比對。

4、線上環(huán)境灰度實驗：灰度對于重構非常重要，我們利用已有的ABTest平臺，逐步放開灰度流量，從5%、到10%、到30%、最后到100%，制定了很謹慎的放量節(jié)奏，然后通過日志以及業(yè)務指標監(jiān)控進行驗證。

寫在最后

回顧整個重構的過程，總結成下面 7 個關鍵點：

7、小心求證，為每行代碼負責

當然，最關鍵的因素還是人，大型項目重構極其考驗團隊的協(xié)作能力，如果每個人都很靠譜，重構就已經(jīng)成功了一半。

特別推薦一個分享架構+算法的優(yōu)質(zhì)內(nèi)容，還沒關注的小伙伴，可以長按關注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝