[[214933]]

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

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

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

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

備份

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

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

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

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

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

寫測試

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

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

日志監(jiān)控

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

這個簡單的技巧可以將每一個后端應(yīng)用變成一個像真實的簿記系統(tǒng)一樣，而像一個真正的簿記系統(tǒng)，所有數(shù)字必須匹配，如果它們在某個地方對不上就有問題。

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

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

一次只修改一處

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

修改平臺

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

修改架構(gòu)

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

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

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

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

修復(fù) bug

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

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

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

按著路線圖執(zhí)行

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

任何時候都不要嘗試徹底重寫

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

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

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

發(fā)布！

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

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

使用代理的好處

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

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

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