原標(biāo)題:拯救你的舊代碼庫,不得不看的 11 條軍規(guī)
每個程序員、項(xiàng)目經(jīng)理或團(tuán)隊(duì)負(fù)責(zé)人的職業(yè)生涯中至少會遇到一次這樣的事件:你接手一坨超過百萬行代碼的系統(tǒng),原來的程序員很久以前就離職,現(xiàn)在也許正在某個陽光明媚的地方度假,文檔(如果有的話)最有可能的情況就是與現(xiàn)有的系統(tǒng)不同步。而你的工作則是帶領(lǐng)團(tuán)隊(duì)脫離這個混亂。
在經(jīng)歷逃離的本能回應(yīng)之后,你開始對項(xiàng)目進(jìn)行了了解,通過你手頭現(xiàn)有的東西,失敗是大概率發(fā)生的事件。但是,公司高層領(lǐng)導(dǎo)是不能容忍項(xiàng)目失敗的結(jié)果發(fā)生。你該如何應(yīng)對?
這時,如果能夠把這些垃圾代碼變成健康的可維護(hù)的項(xiàng)目,實(shí)際上是非常值得一試的事情。以下是我們總結(jié)的改進(jìn)舊版代碼庫的一些經(jīng)驗(yàn)(或者叫軍規(guī))。
改進(jìn)舊代碼庫的 11 條軍規(guī) ——
數(shù)據(jù)備份
我們很難記得每天修改了哪些東西,特別是配置數(shù)據(jù)容易受到這種問題的影響。配置通常不會進(jìn)行版本控制,如果能夠進(jìn)行定期備份,則可以規(guī)避很多麻煩。
在開始做任何事情之前,你需要備份所有可能相關(guān)的內(nèi)容,放到一個非常安全的地方,確保不管發(fā)生什么情況都不會丟失數(shù)據(jù)。
構(gòu)建一個真實(shí)的仿真環(huán)境
構(gòu)建一個真實(shí)的仿真環(huán)境是重要的先決條件,第一步是你確保知道現(xiàn)在正在生產(chǎn)環(huán)境運(yùn)行的是什么,這意味著你能夠構(gòu)建一個軟件版本和你的真實(shí)環(huán)境保持一致,相同的軟件環(huán)境與二進(jìn)制版本。
如果你找不到一個方法來實(shí)現(xiàn)這一點(diǎn),假如你提交代碼到生產(chǎn)環(huán)境,就可能會遇到一些令人不快的意外。確保新的代碼在合適環(huán)境盡可能地被測試,然后你才會有足夠的信心將其運(yùn)行到生產(chǎn)環(huán)境。
上線時做好準(zhǔn)備可以隨時切換回老的代碼,并確保通過日志記錄可以了解相關(guān)重要內(nèi)容,以便在后續(xù)排查問題時能派上用場。
凍結(jié) DB 修改
盡可能凍結(jié)數(shù)據(jù)庫修改,當(dāng)完成第一階段的改進(jìn),直到團(tuán)隊(duì)對代碼庫有了徹底的了解,遺留代碼已經(jīng)棄之不用時,才考慮修改數(shù)據(jù)庫結(jié)構(gòu)。在此之前任何的數(shù)據(jù)庫修改都可能會導(dǎo)致一些棘手的問題,讓你失去并行運(yùn)行舊系統(tǒng)和新的代碼庫的能力。
保持 DB 完全不變,你可以比較新的業(yè)務(wù)邏輯代碼與舊的業(yè)務(wù)邏輯代碼,如果所有這些效果都與預(yù)期一樣,則應(yīng)該完全沒有區(qū)別。
編寫測試
在進(jìn)行任何修改之前,編寫盡可能多的端到端以及集成測試,確保這些測試能夠產(chǎn)生正確的輸出,并覆蓋所有潛在的情況。
這些測試將具有兩個重要功能:一方面,幫助技術(shù)在早期階段清除任何誤解;另外一方面,一旦你開始編寫新代碼來替換舊代碼,這些測試將可以更好保護(hù)您的系統(tǒng)。
自動化你的所有測試,如果你已經(jīng)有 CI 的經(jīng)驗(yàn)則盡快使用它,并確保您的測試運(yùn)行足夠快,以便在每次提交后運(yùn)行全套測試。
Instrumentation 和日志
如果舊平臺仍然可以增加 Instrumentation,在一個全新的數(shù)據(jù)庫表中執(zhí)行此操作,為你可以考慮的每個事件添加一個簡單的計(jì)數(shù)器,并添加一個單個函數(shù)來實(shí)現(xiàn)此功能,以根據(jù)事件的名稱來增加這些計(jì)數(shù)器。
這樣,你可以使用一些額外的代碼行實(shí)現(xiàn)帶有時間戳的事件日志,你將了解到有多少事件導(dǎo)致另一種事件。
舉例來說,用戶打開應(yīng)用程序,用戶關(guān)閉應(yīng)用程序。如果兩個事件導(dǎo)致一些后端請求,那么這兩個計(jì)數(shù)器應(yīng)該在長期上保持不變,差異是當(dāng)前打開的應(yīng)用程序的數(shù)量。
如果你看到更多的應(yīng)用程序打開,而不是應(yīng)用程序關(guān)閉,你知道必須有另一種應(yīng)用程序結(jié)束的方式(例如崩潰)。
這個簡單的技巧可以將每個后端應(yīng)用程序變成一個類似的簿記(bookkeeping)系統(tǒng),就像一個真正的簿記系統(tǒng)那樣,所有的數(shù)字必須匹配,確保它們在所有用到的地方?jīng)]有問題。
隨著時間的推移,這個系統(tǒng)的健康監(jiān)控變得非常寶貴,并且將成為源代碼控制系統(tǒng)變更日志的一個很好的伴侶,你可以在其中確定每個錯誤引入的時間點(diǎn),以及對各種情況產(chǎn)生影響的計(jì)數(shù)。
我通常保留這些計(jì)數(shù)器的分辨率為 5 分鐘(因此每小時記錄 12次),但如果你的系統(tǒng)有更少或更多事件,則可能需要修改這個時間間隔。所有計(jì)數(shù)器使用同一個數(shù)據(jù)庫表,因此每個計(jì)數(shù)器只是該表中的一列。
每次只修改一個點(diǎn)
在添加新功能或修復(fù)錯誤的同時,不要陷入同時改進(jìn)代碼以及修改代碼運(yùn)行平臺的陷阱。這會導(dǎo)致很多頭大的問題。
平臺遷移
如果你決定將應(yīng)用程序遷移到另一個平臺,那么請先執(zhí)行此操作,但要保持一切功能完全一樣。你可以添加更多的文檔或測試,但不能超過這一點(diǎn),所有業(yè)務(wù)邏輯和相互依賴關(guān)系應(yīng)該保持原樣。
架構(gòu)變化
接下來要解決的是改變應(yīng)用程序的架構(gòu)(如果需要)。這個時候,你可以隨意更改代碼的較高級別結(jié)構(gòu),通常通過減少模塊之間的水平鏈接數(shù)量,從而減少與最終用戶進(jìn)行任何交互時代碼活動的范圍。
如果舊代碼本質(zhì)上是一體的,現(xiàn)在將是一個很好的時機(jī)使其更加模塊化,將大型功能分解成較小的功能,但是保留變量和數(shù)據(jù)結(jié)構(gòu)的名稱。
架構(gòu)修改并不總是可行,如果特別不幸運(yùn),那么可能需要非常深入理解代碼才能進(jìn)行任何架構(gòu)更改。
如果你同時進(jìn)行高級別更改和低級別更改,至少需要將其限制在一個文件,或最壞情況下限制在一個子系統(tǒng),以便盡可能限制更改的范圍。否則你可能很難調(diào)試剛才所做的更改。
低級重構(gòu)
到目前為止,你應(yīng)該對每個模塊的功能有很好的了解,并為實(shí)際工作做好準(zhǔn)備:重構(gòu)代碼以提高可維護(hù)性,并使代碼具備擴(kuò)展新功能的能力。
這很可能是項(xiàng)目中耗時最多的一部分,文檔需要隨之進(jìn)行,在完整編寫文檔介紹并徹底了解一個模塊之前,不要隨意更改模塊。
這個階段也可以修改變量和函數(shù)命名、修改數(shù)據(jù)結(jié)構(gòu),以提高代碼清晰度和一致性。記得添加相關(guān)測試代碼(根據(jù)需要,可進(jìn)行單元測試)。
修復(fù) bug
現(xiàn)在你準(zhǔn)備好進(jìn)行一些最終用戶可見的變化,第一件事情將是修復(fù)多年來積累在隊(duì)列中的 bug。
像往常一樣,首先確認(rèn) bug 仍然存在,然后編寫一個測試并修復(fù) bug,你的持續(xù)集成和端到端的測試可以幫你避免由于缺乏理解或某些錯誤而導(dǎo)致的任何錯誤及外圍問題。
數(shù)據(jù)庫升級
如果上述工作都已經(jīng)完成,你可以再次擁有可靠且可維護(hù)的代碼庫,你可以選擇更改數(shù)據(jù)庫 schema 甚至替換數(shù)據(jù)庫。
已經(jīng)完成的上述工作都將有助于您以無負(fù)擔(dān)的方式進(jìn)行變革,而無需擔(dān)心任何意外,你可以使用新的代碼和所有的測試來測試新的數(shù)據(jù)庫,以確保你的遷移沒有任何問題。
更穩(wěn)健的重構(gòu)之路
在路線圖上前行
恭喜,到這里你已經(jīng)走出了叢林,現(xiàn)在已經(jīng)準(zhǔn)備好可以實(shí)施任 功能了。
不要嘗試徹底重寫
徹底重寫是一種幾乎保證會失敗的項(xiàng)目。
一方面,你是在未知的領(lǐng)域開始,你甚至不知道要重構(gòu)什么。
另一方面,你也將所有的問題推到最后一天,就在你用新系統(tǒng)啟用之前的那一天。很悲劇的是,那也是你失敗的時刻。
業(yè)務(wù)邏輯的假設(shè)最終會證實(shí)存在問題,那時你將突然了解到為什么舊系統(tǒng)會用某種奇怪的方式來工作,最終也會意識到能將舊系統(tǒng)放在一起工作的人也不都是白癡。
如果你真的想要將公司(以及你自己的信譽(yù))帶向一個泥潭,就來一個徹底大重寫吧!但如果你足夠聰明,徹底重寫系統(tǒng)通常不會成為會議桌上的一個討論選項(xiàng)。
替代方案:迭代式改進(jìn)
要解開這些線團(tuán)最快的方法就是從你已經(jīng)理解的代碼入手(它可能是一個外圍設(shè)備,但也可能是一些核心模塊),并在它的舊的上下文的范圍內(nèi)嘗試逐步改進(jìn)。
如果舊的構(gòu)建工具不再可用,你將不得不使用一些技巧(見下文),但至少在你開始更改時,盡可能多地保持舊的系統(tǒng)工作。一個典型的提交通常只包含數(shù)行代碼。
發(fā)布到生產(chǎn)環(huán)境
所有修改盡可能發(fā)布到生產(chǎn)環(huán)境,即使修改的代碼是最終用戶不可見的,因?yàn)楫?dāng)你對系統(tǒng)了解不足時,只有生產(chǎn)環(huán)境才會告訴你,新的修改哪里會有問題。
如果這個問題只是在小的改變之后出現(xiàn),你將獲得幾個優(yōu)勢:
很容易弄清楚出了什么問題
處于改善流程的良好狀態(tài)
立即更新文檔,以記錄獲得的新見解
合理使用代理服務(wù)器
如果你正在重構(gòu)一個 Web 系統(tǒng),你可以在最終用戶和舊系統(tǒng)之間部署一個代理服務(wù)器。你可以 控制每個 URL,哪些請求進(jìn)入舊系統(tǒng),哪些請求路由到新系統(tǒng),從而可以更輕松,更精細(xì)地控制運(yùn)行的內(nèi)容。
如果你的代理足夠強(qiáng)大,你甚至可以控制將某個 URL 一定百分比的流量發(fā)送到新系統(tǒng),以便觀察新系統(tǒng)的運(yùn)行情況。如果你的集成測試也能夠連接到這個代理,那就更好了。
結(jié)語
如果按照這些步驟進(jìn)行,確實(shí)存在不少工作,但是它的確有效,而且這個過程的任何優(yōu)化都讓你進(jìn)一步徹底了解整個系統(tǒng)。
有時候如果公司系統(tǒng)已經(jīng)出現(xiàn)問題,而且可能會影響客戶時,如果按照這個流程進(jìn)行可能使事情好轉(zhuǎn),我寧愿完全控制和使用這個過程,而不是為了表面的節(jié)省幾天或幾周時間的方式。
如果你更多地是激進(jìn)的做事方式,你的老板也同意,也許那是可以接受的高風(fēng)險(xiǎn)方式,但是大多數(shù)公司寧愿采取稍慢一點(diǎn),更穩(wěn)健的重構(gòu)之路。
投稿郵箱:chuanbeiol@163.com 詳情請?jiān)L問川北在線:http://m.sanmuled.cn/