完美世界手游官网隐藏任务 www.gytoi.icu 今天講述一個代碼重構的經歷。

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

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

那是一個周六的早上,我當時不在廣州,而是去了深圳,去一個同學家。當時跟我同學聊的盡興,就一直沒看手機,間隔了一個多小時后,我打開微信一開,工作群里有幾百個未讀??吹轎頤羌際醺涸鶉說耐廢褚恢痹諫煉?,就意識到應該是出大問題了。

圖0:代碼重構!你敢嗎?

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

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

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

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

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

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

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

確定重構的范圍

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

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

覺得這樣肯定不行。

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

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

設計好驗證的方式

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

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

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

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

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

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

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

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

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

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

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

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

灰度,一定要灰度

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

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

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

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

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

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

控制好各方預期

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

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

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

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

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

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

結語

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

余下全文(1/3)
分享這篇文章:

請關注我們:

發表評論

電子郵件地址不會被公開。 必填項已用*標注