來自：程序人生“孩子，閣樓的那扇小門，輕易不要打開哦……”童話裡的老人一臉諱莫如深。那鎖在閣樓裡的老代碼，你敢動嗎？非動不可的時候，又要怎麼動呢？作為微信早期員工、騰訊資深架構師、技術 Leader，大飛從高中便開始接觸編程，大學通過校招實習生進入騰訊，這麼一呆便是十年。算是微信部門的“資深大牛”，做過一線技術小兵，帶過團隊，做過產品，在工程技術上有豐富的經驗。而頂著一系列閃光標籤的他在剛轉調業務部門的檔口，也撞上了代碼重構的麻煩事兒……
作者 | 大飛
今天講述一個代碼重構的經歷。
2014 年，我從基礎架構部門，轉調到業務部門。技術負責人想讓我搞定業務系統的穩定性問題。
當時的業務系統確實存在不少問題，不過我初來乍到，對整體系統不熟悉，就想在熟悉一段時間後再動手。沒想到，後面是事情自己找上了門。
那是一個週六的早上，我當時不在廣州，而是去了深圳的一個同學家。當時跟我同學聊得盡興，就一直沒看手機，間隔了一個多小時後，我打開微信一看，工作群裡有幾百個未讀。看到我們技術負責人的頭像一直在閃動，就意識到應該是出大問題了。
原來，是一個核心的業務系統出了一個 bug， 影響到了一個重要的商戶。
他們本意是給一個用戶推送一條特定消息，消息裡面還包含了一些隱私信息。不巧，一個新來的同學因為一個新的需求，修改了那部分的代碼，引入了一個 bug , 導致本來是發個一個特定用戶的信息，發給了一堆人。
商戶相當不滿，後來是部門的公關出面，才將事情平息下來，經理那邊也因為這個事情，拉我們到辦公室批了一頓。
技術負責人也壓力山大。我們幾個人在會議室裡討論了很久，最後大家都覺得如果要比較好地杜絕此類問題，除了要加強各種測試等措施外，還有一個，就是要重構現有的代碼。
因為這個系統是最核心的業務系統之一，而且幾經易手，當時的代碼已經變得極難維護，裡面各種 if else 的分支，還有長達一千行一個的函數，註釋不全，文檔也不足，要想長期的維護下去，這個技術債是非償還不可了。
大家面面相覷，雖然知道重構是最好的解決方案，但大家都不想搞呀。
後來，我考慮到，初來這裡還是要做些事情才能得到大家的認可，就硬著頭皮，把重構的這個任務給接了下來。
確定重構的範圍
接下這個任務後，我和項目組的成員就開始分析這個系統。
發現這個系統的業務流程很長，涉及到幾十個子系統（微服務），還依賴幾個外部門的服務。如果全部重構下來，估計一年都做不完，而且風險極大，重構一年的系統，然後再上線，誰敢呀，而且到那時，說不定黃花菜都涼了。
這樣肯定不行。
我們就重新梳理了一遍，把整個系統劃分成了三個部分，我們發現中間部分的修改最頻繁，出問題的頻率也最大，就決定先重構中間流程部分的代碼。
項目規劃部分，我們對項目進行了分期，中間部分的重構作為第一期，其他兩部分可以作為二期、三期項目來做。一個是可以極大地減少壓力，使得事情更加容易把握，另一個是間隔一段時間有產出也能給團隊帶來信心。
設計好驗證的方式
當確認好重構的範圍後，接下來的事情，就是要考慮如何來驗證重構後的代碼了。
這個是重構代碼最重要的一個部分，如果沒辦法驗證重構代碼的正確性，你是不敢上線的，就算硬上了，也會睡不好覺。
一般重構代碼的驗證，可以採用測試代碼，測試用例覆蓋的方法（這部分可以參考 《重構》）。但我們發現，要重構的這個部分不能採用這種方式來驗證。
因為業務邏輯很複雜，而且涉及到太多的外圍系統，一個是測試用例很難覆蓋全面，另外一個是沒有辦法可以很好地隔離外部系統的依賴。
我們分析了整個系統，發現這個系統的功能是，接受商戶過來一個請求，然後進行各種權限、角色等的判斷，再根據各個參數去各個依賴系統拉取數據，最後組裝出一個新的包，再把這個新的包發送到隔壁部門的下游系統。
後來，我們想了雙流程驗證的方案。
我們將重構部分的代碼全部封裝起來，然後提供一個新的接口，一個請求進來後，我們分別執行舊的業務邏輯，也將請求發給新接口。在流程的最後，我們將新舊流程構造出的字段，進行逐個字段的對比。新流程只驗證正確性，不做實際的輸出。
為了保證驗證的效果，驗證要在線上進行，所以還要再結合後面的灰度流程。
盡一切努力，搞清重構代碼的邏輯
當我們確定好驗證方式後，接下來就是正式的工作了，重構代碼。重寫代碼本身是不難的，但遇到的麻煩是，幾乎沒有文檔，註釋也很少，通過看代碼只是搞懂了百分之五十左右的邏輯，還有一大部分的邏輯，無法理清楚。
後來，我們想到一個辦法，把代碼版本管理系統的 log 全部拉出來。通過 log 我們找到了各部分邏輯不清晰的代碼的負責人，然後一個一個地去跟他們聊，跟他們請教。運氣好的是，大部分人員都還在，中間還跟產品經理聊了不少，終於，把整個邏輯搞懂了百分之九十幾。
因為有了上面的雙流程驗證和下面灰度邏輯，我們覺得，可以開始上線驗證了。
灰度，一定要灰度
接下來，就要開始我們的灰度驗證流程了。因為故障的影響很大，所以我們灰度得特別小心。
我們內部有灰度系統，但內部系統的灰度粒度比較大，為了保險我們需要更小粒度的灰度，所以我們自己寫了灰度的邏輯代碼，直接嵌入到了系統裡面。
一開始的時候，極度小心，幾乎是一個商戶一個商戶灰度的。灰度完後，我們每間隔一段時間，就分析一遍 log 和監控，看看有沒有隱藏的問題。
最終，我們確實在這個灰度的過程中，發現了不少問題，不過因為涉及的用戶很少，都沒有造成大的影響。
這種極小範圍的灰度，大概持續了一週左右的時間，後面慢慢加快了灰度的速度。大概花了一個月的時間，覆蓋了全部的用戶。
中間過程幾乎沒有出現什麼大的問題，可以說是比較成功的一次重構。
控制好各方預期
最後一個點，跟技術無關，是關於相關人員的預期，包括上級的預期，同級的預期，下屬的預期。
我當時知道這個項目有難度，自己心裡也沒底，所以跟上級說去試一試，後來談成可以在過程接受兩次中等故障。當然最後結果比預期好，沒有一次中等故障，只有過兩次小故障。
同級這塊，也是跟大家說，盡力去試試，不過確實不是很有把握，也算是降低了他們的預期。
對於下面的兄弟，我是跟大家說，這是一件可以穩固我們團隊地位的事情，拼死也要拿下這一仗。後面大家都很齊心，一起完成了這個在當時看來挺難的一個任務。
這個策略，是我第一年工作的時候，我導師告訴我的，內緊外鬆。這樣外面對你的預期比較低，內部卻很拼命地做，最後的結果，往往比較容易超出大家的預期。
我覺得這是一個很好的策略。
結語
最後，我們順利完成了這次的重構任務，也做出了我們在新團隊的影響力。後面再來回顧，發現我們做對了不少事情。沒有一上來就開幹，因為信心不足，反而是小心翼翼，也正是因為信心不太足，同時在不斷降低外界的預期，最後一步一步，緊遵流程，獲得了不錯的結果。
閱讀更多 真致信息技術 的文章
