今天講述一個代碼重構的經歷。

2014年，我從基礎架構部門，轉調到業務部門。技術負責人想讓我搞定業務系統的穩定性問題。

當時的業務系統確實存在不少問題，不過我初來乍到，對整體系統不熟悉，就想在熟悉一段時間后再動手。沒想到，后面是事情自己找上了門。

那是一個周六的早上，我當時不在廣州，而是去了深圳，去一個同學家。當時跟我同學聊的盡興，就一直沒看手機，間隔了一個多小時后，我打開微信一開，工作群里有幾百個未讀。看到我們技術負責人的頭像一直在閃動，就意識到應該是出大問題了。

原來，是一個核心的業務系統出了一個bug， 影響到了一個重要的商戶。

他們本意是給一個用戶推送一條特定消息，消息里面還包含了一些隱私信息。不巧，一個新來的同學因為一個新的需求，修改了那部分的代碼，引入了一個bug , 導致本來是發個一個特定用戶的信息，發給了一堆人。

商戶相當不滿，后來是部門的公關出面，才將事情平息下來，經理那邊也因為這個事情，拉我們到辦公室批了一頓。

技術負責人也壓力山大。我們幾個人，在會議室里討論了很久，***大家都覺得如果要比較好的杜絕此類的問題，除了要加強各種測試等措施外，還有一個，就是要重構現有的代碼。

因為這個系統是最核心的業務系統之一，而且幾經易手，當時的代碼已經變得極難維護，里面各種if else 的分支，還有長達一千行一個的函數，注釋不全，文檔也不足，要想長期的維護下去，這個技術債是非償還不可了。

大家面面相覷，雖然知道重構是***的解決方案，但大家都不想搞呀。

后來，我考慮到，初來這里還是要做些事情才能得到大家認可的，就硬著頭皮，把重構的這個任務給接了下來。

確定重構的范圍

接下這個任務后，我和項目組的成員就開始分析這個系統。

發現這個系統的業務流程很長，涉及到幾十個子系統(微服務)，還依賴幾個外部門的服務。如果全部重構下來，估計一年都做不完，而且風險極大，重構一年的系統，然后再上線，誰敢呀，而且到那時，說不定黃花菜都涼了。

覺得這樣肯定不行。

我們就重新梳理了一遍，把整個系統劃分成了三個部分，我們發現中間部分的修改最頻繁，出問題的頻率也***，就決定先重構中間流程部分的代碼。

項目規劃部分，我們對項目進行了分期，中間部分的重構作為***期，其他兩部分可以作為二期，三期項目來做。一個是可以極大地減少壓力，使得的事情更加容易把握，另一個是間隔一段時間有產出也能給團隊帶來信心。

設計好驗證的方式

當確認好重構的范圍后，接下來的事情，就是要考慮如何來驗證重構后的代碼了。

這個是重構代碼最重要的一個部分，如果沒辦法驗證重構代碼的正確性，你是不敢上線的，就算硬上了，也會睡不好覺。

一般重構代碼的驗證，可以采用測試代碼，測試用例覆蓋的方法。(這部分可以參考 《重構》)。但我們發現，我們要重構的這個部分，不能采用這種方式來驗證。

因為業務邏輯很復雜，而且涉及到太多的外圍系統，一個是測試用例很難覆蓋全面，另外一個是沒有辦法可以很好的隔離外部系統的依賴。

我們分析了整個系統，發現這個系統的功能是，接受商戶過來一個請求，然后進行各種權限，角色等的判斷，再根據各個參數去各個依賴系統拉取數據，***組裝出一個新的包，再把這個新的包發送到隔壁部門的下游系統。

后來，我們想了雙流程驗證的方案。

我們將重構部分的代碼，全部封裝起來，然后提供一個新的接口，一個請求進來后，我們分別執行舊的業務邏輯，也將請求發給新接口。在流程的***，我們將新舊流程構造出的字段，進行逐個字段的對比。新流程只驗證正確性，不做實際的輸出。

為了保證驗證的效果，驗證要在線上進行，所以還要再結合后面的灰度流程。

盡一切努力，搞清重構代碼的邏輯

當我們確定好驗證方式后，接下來就是正式的工作了，重構代碼。重寫代碼本身是不難的，但遇到的麻煩是，幾乎沒有文檔，注釋也很少，通過看代碼只是搞懂了百分之五十左右的邏輯，還有一大部分的邏輯，無法理清楚。

后來，我們想到一個辦法，把代碼版本管理系統的log 全部拉出來。通過log我們找到了各部分邏輯不清晰的代碼的負責人，然后一個一個的去跟他們聊，跟他們請教。運氣好的是，大部分的人員都還在，中間還跟產品經理聊了不少，終于，把整個的邏輯搞懂了百分之九十幾。

因為有了上面的雙流程驗證和下面灰度邏輯，我們覺得，可以開始上線驗證了。

灰度，一定要灰度

接下來，就要開始我們的灰度驗證流程了。因為故障的影響很大，所以我們灰度的特別小心。

我們內部有灰度系統，但內部系統的灰度粒度比較大，為了保險我們需要更小粒度的灰度，所以我們自己寫了灰度的邏輯代碼，直接嵌入到了系統里面。

一開始的時候，極度小心，幾乎是一個商戶，一個商戶灰度的。灰度完后，我們每間隔一段時間，就分析一遍log和監控，看看有沒有隱藏的問題。

最終，我們確實在這個灰度的過程中，發現了不少的問題，不過因為涉及的用戶很少，都沒有造成大的影響。

這種極小范圍的灰度，大概持續了一周左右的時間，后面慢慢加快了灰度的速度。大概花了一個月的時間，覆蓋了全部的用戶。

中間過程，幾乎沒有出現什么大的問題，可以說是比較成功的一次重構。

控制好各方預期

***一個點，跟技術無關，是關于相關人員的預期，包括上級的預期，同級的預期，下屬的預期。

我當時知道這個項目有難度，自己心里也沒底，所以跟上級說去試一試，后來談成可以在過程接受兩次中等故障。當然***結果比預期好，沒有一次中等故障，只有過兩次小故障。

同級這塊，也是跟大家說，盡力去試試，不過確實不是很有把握，也算是降低了他們的預期。

對于下面的兄弟，我是跟大家說，這是一件可以穩固我們團隊地位的事情，拼死也要拿下這一仗。后面大家都很齊心，一起完成了這個在當時看來挺難的一個任務。

這個策略，是我***年工作的時候，我導師告訴我的，內緊外松。這樣外面對你的預期是比較低，內部卻很拼命的做，***的結果，往往比較容易超出大家的預期。

我覺得這是一個很好的策略。

結語

***，我們順利完成了這次的重構任務，也做出了我們在新團隊的影響力。后面再來回顧，發現我們做對了不少的事情。沒有一上來就開干，因為信心不足，反而是小心翼翼，也因為信心不太足，在不斷的降低外界的預期，***一步一步，緊遵流程，獲得了不錯的結果。