[[214933]]

在每一個(gè)程序員、項(xiàng)目管理員、團(tuán)隊(duì)領(lǐng)導(dǎo)的一生中，這都會(huì)至少發(fā)生一次。原來(lái)的程序員早已離職去度假了，給你留下了一坨幾百萬(wàn)行屎一樣的、勉強(qiáng)支撐公司運(yùn)行的代碼和（如果有的話）跟代碼驢頭不對(duì)馬嘴的文檔。

你的任務(wù)：帶領(lǐng)團(tuán)隊(duì)擺脫這個(gè)混亂的局面。

當(dāng)你的***反應(yīng)（逃命）過(guò)去之后，你開(kāi)始去熟悉這個(gè)項(xiàng)目。公司的管理層都在關(guān)注著你，所以項(xiàng)目只能成功；然而，看了一遍代碼之后卻發(fā)現(xiàn)失敗幾乎是不可避免。那么該怎么辦呢？

幸運(yùn)（不幸）的是我已經(jīng)遇到好幾次這種情況了，我和我的小伙伴發(fā)現(xiàn)將這坨熱氣騰騰的屎變成一個(gè)健康可維護(hù)的項(xiàng)目是一個(gè)有豐厚利潤(rùn)的業(yè)務(wù)。下面這些是我們的一些經(jīng)驗(yàn)：

備份

在開(kāi)始做任何事情之前備份與之可能相關(guān)的所有文件。這樣可以確保不會(huì)丟失任何可能會(huì)在另外一些地方很重要的信息。一旦修改了其中一些文件，你可能花費(fèi)一天或者更多天都解決不了這個(gè)愚蠢的問(wèn)題。配置數(shù)據(jù)通常不受版本控制，所以特別容易受到這方面影響，如果定期備份數(shù)據(jù)時(shí)連帶著它一起備份了，還是比較幸運(yùn)的。所以謹(jǐn)慎總比后悔好，復(fù)制所有東西到一個(gè)絕對(duì)安全的地方并不要輕易碰它，除非這些文件是只讀模式。

重要的先決條件：必須確保代碼能夠在生產(chǎn)環(huán)境下構(gòu)建運(yùn)行并產(chǎn)出

之前我假設(shè)環(huán)境已經(jīng)存在，所以完全丟了這一步，但 Hacker News 的眾多網(wǎng)友指出了這一點(diǎn)，并且事實(shí)證明他們是對(duì)的：***步是確認(rèn)你知道在生產(chǎn)環(huán)境下運(yùn)行著什么東西，也意味著你需要在你的設(shè)備上構(gòu)建一個(gè)跟生產(chǎn)環(huán)境上運(yùn)行的版本每一個(gè)字節(jié)都一模一樣的版本。如果你找不到實(shí)現(xiàn)它的辦法，一旦你將它投入生產(chǎn)環(huán)境，你很可能會(huì)遭遇一些預(yù)料之外的糟糕事情。確保每一部分都盡力測(cè)試，之后在你足夠確信它能夠很好的運(yùn)行的時(shí)候?qū)⑺渴鹕a(chǎn)環(huán)境下。無(wú)論它運(yùn)行的怎么樣都要做好能夠馬上切換回舊版本的準(zhǔn)備，確保日志記錄下了所有情況，以便于接下來(lái)不可避免的 “驗(yàn)尸” 。

凍結(jié)數(shù)據(jù)庫(kù)

直到你修改代碼結(jié)束之前盡可能凍結(jié)你的數(shù)據(jù)庫(kù)，在你已經(jīng)非常熟悉代碼庫(kù)和遺留代碼之后再去修改數(shù)據(jù)庫(kù)。在這之前過(guò)早的修改數(shù)據(jù)庫(kù)的話，你可能會(huì)碰到大問(wèn)題，你會(huì)失去讓新舊代碼和數(shù)據(jù)庫(kù)一起構(gòu)建穩(wěn)固的基礎(chǔ)的能力。保持?jǐn)?shù)據(jù)庫(kù)完全不變，就能比較新的邏輯代碼和舊的邏輯代碼運(yùn)行的結(jié)果，比較的結(jié)果應(yīng)該跟預(yù)期的沒(méi)有差別。

寫測(cè)試

在你做任何改變之前，盡可能多的寫一些端到端測(cè)試和集成測(cè)試。確保這些測(cè)試能夠正確的輸出，并測(cè)試你對(duì)舊的代碼運(yùn)行的各種假設(shè)（準(zhǔn)備好應(yīng)對(duì)一些意外狀況）。這些測(cè)試有兩個(gè)重要的作用：其一，它們能夠在早期幫助你拋棄一些錯(cuò)誤觀念，其二，這些測(cè)試在你寫新代碼替換舊代碼的時(shí)候也有一定防護(hù)作用。

要自動(dòng)化測(cè)試，如果你有 CI 的使用經(jīng)驗(yàn)可以用它，并確保在你提交代碼之后 CI 能夠快速的完成所有測(cè)試。

日志監(jiān)控

如果舊設(shè)備依然可用，那么添加上監(jiān)控功能。在一個(gè)全新的數(shù)據(jù)庫(kù)，為每一個(gè)你能想到的事件都添加一個(gè)簡(jiǎn)單的計(jì)數(shù)器，并且根據(jù)這些事件的名字添加一個(gè)函數(shù)增加這些計(jì)數(shù)器。用一些額外的代碼實(shí)現(xiàn)一個(gè)帶有時(shí)間戳的事件日志，你就能大概知道發(fā)生多少事件會(huì)導(dǎo)致另外一些種類的事件。例如：用戶打開(kāi) APP 、用戶關(guān)閉 APP 。如果這兩個(gè)事件導(dǎo)致后端調(diào)用的數(shù)量維持長(zhǎng)時(shí)間的不同，這個(gè)數(shù)量差就是當(dāng)前打開(kāi)的 APP 的數(shù)量。如果你發(fā)現(xiàn)打開(kāi) APP 比關(guān)閉 APP 多的時(shí)候，你就必須要知道是什么原因?qū)е?APP 關(guān)閉了（例如崩潰）。你會(huì)發(fā)現(xiàn)每一個(gè)事件都跟其它的一些事件有許多不同種類的聯(lián)系，通常情況下你應(yīng)該盡量維持這些固定的聯(lián)系，除非在系統(tǒng)上有一個(gè)明顯的錯(cuò)誤。你的目標(biāo)是減少那些錯(cuò)誤的事件，盡可能多的在開(kāi)始的時(shí)候通過(guò)使用計(jì)數(shù)器在調(diào)用鏈中降低到指定的級(jí)別。（例如：用戶支付應(yīng)該得到相同數(shù)量的支付回調(diào)）。

這個(gè)簡(jiǎn)單的技巧可以將每一個(gè)后端應(yīng)用變成一個(gè)像真實(shí)的簿記系統(tǒng)一樣，而像一個(gè)真正的簿記系統(tǒng)，所有數(shù)字必須匹配，如果它們?cè)谀硞€(gè)地方對(duì)不上就有問(wèn)題。

隨著時(shí)間的推移，這個(gè)系統(tǒng)在監(jiān)控健康方面變得非常寶貴，而且它也是使用源碼控制修改系統(tǒng)日志的一個(gè)好伙伴，你可以使用它確認(rèn) BUG 引入到生產(chǎn)環(huán)境的時(shí)間，以及對(duì)多種計(jì)數(shù)器造成的影響。

我通常保持每 5 分鐘（一小時(shí) 12 次）記錄一次計(jì)數(shù)器，但如果你的應(yīng)用生成了更多或者更少的事件，你應(yīng)該修改這個(gè)時(shí)間間隔。所有的計(jì)數(shù)器公用一個(gè)數(shù)據(jù)表，每一個(gè)記錄都只是簡(jiǎn)單的一行。

一次只修改一處

不要陷入在提高代碼或者平臺(tái)可用性的同時(shí)添加新特性或者是修復(fù) BUG 的陷阱。這會(huì)讓你頭大，因?yàn)槟悻F(xiàn)在必須在每一步操作想好要出什么樣的結(jié)果，而且會(huì)讓你之前建立的一些測(cè)試失效。

修改平臺(tái)

如果你決定轉(zhuǎn)移你的應(yīng)用到另外一個(gè)平臺(tái)，最主要的是跟之前保持一模一樣。如果你覺(jué)得需要，你可以添加更多的文檔和測(cè)試，但是不要忘記這一點(diǎn)，所有的業(yè)務(wù)邏輯和相互依賴要跟從前一樣保持不變。

修改架構(gòu)

接下來(lái)處理的是改變應(yīng)用的結(jié)構(gòu)（如果需要）。這一點(diǎn)上，你可以自由的修改高層的代碼，通常是降低模塊間的橫向聯(lián)系，這樣可以降低代碼活動(dòng)期間對(duì)終端用戶造成的影響范圍。如果舊代碼很龐雜，那么現(xiàn)在正是讓它模塊化的時(shí)候，將大段代碼分解成眾多小的部分，不過(guò)不要改變量和數(shù)據(jù)結(jié)構(gòu)的名字。

Hacker News 的 mannykannot 網(wǎng)友指出，修改高層代碼并不總是可行，如果你特別不幸的話，你可能為了改變一些架構(gòu)必須付出沉重的代價(jià)。我贊同這一點(diǎn)也應(yīng)該在這里加上提示，因此這里有一些補(bǔ)充。我想額外補(bǔ)充的是如果你修改高層代碼的時(shí)候修改了一點(diǎn)點(diǎn)底層代碼，那么試著只修改一個(gè)文件或者最壞的情況是只修改一個(gè)子系統(tǒng)，盡可能限制修改的范圍。否則你可能很難調(diào)試剛才所做的更改。

底層代碼的重構(gòu)

現(xiàn)在，你應(yīng)該非常理解每一個(gè)模塊的作用了，準(zhǔn)備做一些真正的工作吧：重構(gòu)代碼以提高其可維護(hù)性并且使代碼做好添加新功能的準(zhǔn)備。這很可能是項(xiàng)目中最消耗時(shí)間的部分，記錄你所做的任何操作，在你徹底的記錄并且理解模塊之前不要對(duì)它做任何修改。之后你可以自由的修改變量名、函數(shù)名以及數(shù)據(jù)結(jié)構(gòu)以提高代碼的清晰度和統(tǒng)一性，然后請(qǐng)做測(cè)試（情況允許的話，包括單元測(cè)試）。

修復(fù) bug

現(xiàn)在準(zhǔn)備做一些用戶可見(jiàn)的修改，戰(zhàn)斗的***步是修復(fù)很多積累了幾年的 bug。像往常一樣，首先證實(shí) bug 仍然存在，然后編寫測(cè)試并修復(fù)這個(gè) bug，你的 CI 和端對(duì)端測(cè)試應(yīng)該能避免一些由于不太熟悉或者一些額外的事情而犯的錯(cuò)誤。

升級(jí)數(shù)據(jù)庫(kù)

如果你在一個(gè)堅(jiān)實(shí)且可維護(hù)的代碼庫(kù)上完成所有工作，你就可以選擇更改數(shù)據(jù)庫(kù)模式的計(jì)劃，或者使用不同的完全替換數(shù)據(jù)庫(kù)。之前完成的步驟能夠幫助你更可靠的修改數(shù)據(jù)庫(kù)而不會(huì)碰到問(wèn)題，你可以完全的測(cè)試新數(shù)據(jù)庫(kù)和新代碼，而之前寫的所有測(cè)試可以確保你順利的遷移。

按著路線圖執(zhí)行

祝賀你脫離的困境并且可以準(zhǔn)備添加新功能了。

任何時(shí)候都不要嘗試徹底重寫

徹底重寫是那種注定會(huì)失敗的項(xiàng)目。一方面，你在一個(gè)未知的領(lǐng)域開(kāi)始，所以你甚至不知道構(gòu)建什么，另一方面，你會(huì)把所有的問(wèn)題都推到新系統(tǒng)馬上就要上線的前一天。非常不幸的是，這也是你失敗的時(shí)候。假設(shè)業(yè)務(wù)邏輯被發(fā)現(xiàn)存在問(wèn)題，你會(huì)得到異樣的眼光，那時(shí)您會(huì)突然明白為什么舊系統(tǒng)會(huì)用某種奇怪的方式來(lái)工作，最終也會(huì)意識(shí)到能將舊系統(tǒng)放在一起工作的人也不都是白癡。在那之后。如果你真的想破壞公司（和你自己的聲譽(yù)），那就重寫吧，但如果你是聰明人，你會(huì)知道徹底重寫系統(tǒng)根本不是一個(gè)可選的選擇。

所以，替代方法：增量迭代工作

要解開(kāi)這些線團(tuán)最快方法是，使用你熟悉的代碼中任何的元素（它可能是外部的，也可能是內(nèi)核模塊），試著使用舊的上下文去增量改進(jìn)。如果舊的構(gòu)建工具已經(jīng)不能用了，你將必須使用一些技巧（看下面），但至少當(dāng)你開(kāi)始做修改的時(shí)候，試著盡力保留已知的工作。那樣隨著代碼庫(kù)的提升你也對(duì)代碼的作用更加理解。一個(gè)典型的代碼提交應(yīng)該最多兩三行。

發(fā)布！

每一次的修改都發(fā)布到生產(chǎn)環(huán)境，即使一些修改不是用戶可見(jiàn)的。使用最少的步驟也是很重要的，因?yàn)楫?dāng)你缺乏對(duì)系統(tǒng)的了解時(shí)，有時(shí)候只有生產(chǎn)環(huán)境能夠告訴你問(wèn)題在哪里。如果你只做了一個(gè)很小的修改之后出了問(wèn)題，會(huì)有一些好處：

• 很容易弄清楚出了什么問(wèn)題
• 這是一個(gè)改進(jìn)流程的好位置
• 你應(yīng)該馬上更新文檔展示你的新見(jiàn)解

使用代理的好處

如果你做 web 開(kāi)發(fā)那就謝天謝地吧，可以在舊系統(tǒng)和用戶之間加一個(gè)代理。這樣你能很容易的控制每一個(gè)網(wǎng)址哪些請(qǐng)求定向到舊系統(tǒng)，哪些請(qǐng)求定向到新系統(tǒng)，從而更輕松更精確的控制運(yùn)行的內(nèi)容以及誰(shuí)能夠看到運(yùn)行系統(tǒng)。如果你的代理足夠的聰明，你可以使用它針對(duì)個(gè)別 URL 把一定比例的流量發(fā)送到新系統(tǒng)，直到你滿意為止。如果你的集成測(cè)試也能連接到這個(gè)接口那就更好了。

是的，但這會(huì)花費(fèi)很多時(shí)間！

這就取決于你怎樣看待它了。的確，在按照以上步驟優(yōu)化代碼時(shí)會(huì)有一些重復(fù)的工作步驟。但是它確實(shí)有效，而這里介紹的任何一個(gè)步驟都是假設(shè)你對(duì)系統(tǒng)的了解比現(xiàn)實(shí)要多。我需要保持聲譽(yù)，也真的不喜歡在工作期間有負(fù)面的意外。如果運(yùn)氣好的話，公司系統(tǒng)已經(jīng)出現(xiàn)問(wèn)題，或者有可能會(huì)嚴(yán)重影響到客戶。在這樣的情況下，我比較喜歡完全控制整個(gè)流程得到好的結(jié)果，而不是節(jié)省兩天或者一星期。如果你更多地是牛仔的做事方式，并且你的老板同意可以接受冒更大的風(fēng)險(xiǎn)，那可能試著冒險(xiǎn)一下沒(méi)有錯(cuò)，但是大多數(shù)公司寧愿采取稍微慢一點(diǎn)但更確定的勝利之路。