代碼重構！你敢嗎？

作者 | 大飛

本文經授權轉大飛碼字

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

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

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

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

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

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

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

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

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

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

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

確定重構的範圍

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

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

覺得這樣肯定不行。

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

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

設計好驗證的方式

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

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

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

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

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

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

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

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

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

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

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

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

灰度，一定要灰度

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

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

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

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

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

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

控制好各方預期

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

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

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

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

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

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

結語

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

作者：大飛。十年互聯網人，資深架構師，技術leader。

聲明：版權歸作者所有，如需轉載請聯繫原作者。

【End】

熱 文推 薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！