[[165073]]

遺留代碼最常見的問題就是脆弱性。團(tuán)隊(duì)如要修改脆弱的代碼庫，必定伴隨著巨大的痛楚。在我們 ThoughtWorks 開發(fā)產(chǎn)品的 10 年里，當(dāng)我們年復(fù)一年地盡量保持龐大代碼庫的延展性時(shí)，學(xué)到了一些慘痛的教訓(xùn)。我想在本文分享我們從***挑戰(zhàn)中吸取的教訓(xùn)。聲明：我寫下這些思考，不代表我們已經(jīng)搞定了所有問題。我們?nèi)匀灰謸?dān)遺留代碼的痛苦，和其它團(tuán)隊(duì)一樣，我們每天都努力讓它變得更好一些。

更新所有東東，要一直更新下去

你應(yīng)該一直渴求更新依賴庫和框架。好吧，或許現(xiàn)在已成為共識(shí)。但是，10 年前很少有人這樣想。有些團(tuán)隊(duì)明白，升級(jí)是需要完成的、正確的工作，我只是懷疑，他們是否真地優(yōu)先去做了。它一直需要你認(rèn)真對(duì)待，不要拖到***，變成技術(shù)債務(wù)。原因如下：

• 如果某項(xiàng)任務(wù)是痛點(diǎn)，就要經(jīng)常去做。對(duì)于一直升級(jí)所存在的最明顯的理由之一，就在于升級(jí)會(huì)是艱難的。常常存在不可預(yù)期的、一系列被破壞的依賴。工作量通常無法知曉。經(jīng)常做，它就不再是問題。但是，和簡單的避免痛苦相比，還有更重要的原因。

• 升級(jí)依賴項(xiàng)的另一個(gè)驅(qū)動(dòng)力，在于修復(fù)安全漏洞。現(xiàn)在和 10 年前開發(fā)軟件，有一個(gè)***的不同，我們資源庫、框架和應(yīng)用程序的漏洞報(bào)告仿佛從未間斷過。修復(fù)漏洞，差不多總是涉及到升級(jí)某些依賴項(xiàng)。為了快速修復(fù)漏洞，升級(jí)必須容易操作。

• 沒有定期升級(jí)操作的團(tuán)隊(duì)，通常將其貼上技術(shù)債務(wù)的標(biāo)簽。盡管行業(yè)比 10 年前更樂意談起技術(shù)債務(wù)，但是，說服項(xiàng)目經(jīng)理償還技術(shù)債務(wù)，仍然算得上非常艱難的對(duì)話。如果你的團(tuán)隊(duì)處于「一直升級(jí)所有東東的模式」，你就不用為了升級(jí)技術(shù)債務(wù)而展開溝通。

關(guān)于單元測試

遺留代碼的主要痛點(diǎn)在于，做出修改需要花費(fèi)多長時(shí)間。如果你打算讓代碼長期運(yùn)行下去，就需要確保未來修改代碼的程序員感到完全地開心。有一種處于優(yōu)勢(shì)的方法：極度快速、徹底的單元測試套件。

增加新功能、包括任何代碼重構(gòu)，每個(gè)周期大致描述為：編寫失敗的測試；寫代碼；顯示綠色；搞定。如果你這樣做了，你就能一直執(zhí)行大量的單元測試，有時(shí)候是某一套針對(duì)性的測試、有時(shí)候是整個(gè)套件。如果測試不夠快，開發(fā)周期就不會(huì)輕松。寫代碼的體驗(yàn)不應(yīng)該是：做了一些修改，而運(yùn)行測試卻需要坐等 10 或 20 分鐘。太差勁了。

確保測試套件快速運(yùn)行，不只是與你的設(shè)計(jì)和代碼有關(guān)。誠然，你可以做大量工作來加速測試，比如避免文件、數(shù)據(jù)庫、套接字、海量對(duì)象圖表生成等。但是還有另外的重要技巧，挑選有助于加速測試的框架和語言。如果你發(fā)現(xiàn)自己為了讓測試更快、而修改了框架，那么，你需要考慮不同的框架。是的，當(dāng)我正在開發(fā)傳統(tǒng)的多頁應(yīng)用程序時(shí)，下次就不可能用 Rails 開發(fā)了。

還需要考慮應(yīng)用程序的大小。當(dāng)某個(gè)代碼庫處于一定規(guī)模時(shí)，就需要規(guī)劃好切分方案。這也是讓你充分理解某塊代碼的唯一方法。找到分割項(xiàng)目的切入點(diǎn)，這不同于學(xué)術(shù)上的工作，你需要投入大量時(shí)間折騰代碼、研究各種地方、再設(shè)計(jì)、重構(gòu)。一直讓快速的測試套件迅速地驗(yàn)證你的工作，將使這份工作輕松幾個(gè)數(shù)量級(jí)。

實(shí)際上，「幾個(gè)數(shù)量級(jí)」更像是夸張。如果你需要切分龐大的代碼庫，并忍受著痛苦的、龜速的單元測試套件，嗯，你可能會(huì)被困住。我們正在痛苦地得到教訓(xùn)。因此，盡力確保單元測試要快，并且在開發(fā)機(jī)器上以單一線程運(yùn)行。

「抽象分支」不應(yīng)該是常態(tài)

運(yùn)行時(shí)間長的產(chǎn)品，經(jīng)歷了很多技術(shù)領(lǐng)導(dǎo)。某些類型的技術(shù)領(lǐng)導(dǎo)，剛一接手，就抱怨現(xiàn)有產(chǎn)品的不足，并馬上想開發(fā)新的產(chǎn)品。這沒錯(cuò)。時(shí)髦的技術(shù)不總是糟糕的。對(duì)于長時(shí)間存在的代碼庫，它需要新的活力，產(chǎn)生足夠能量，淘汰不能勝任的地方。我想提兩個(gè)重要的點(diǎn)。

新接手的技術(shù)領(lǐng)導(dǎo)，在和團(tuán)隊(duì)一起工作兩到三個(gè)月之前，不要輕易摒棄任何技術(shù)。有太多的情景需要理解。新接手的技術(shù)領(lǐng)導(dǎo)需要學(xué)會(huì)站在團(tuán)隊(duì)和代碼庫的角度考慮。團(tuán)隊(duì)和技術(shù)領(lǐng)導(dǎo)需要建立信任和節(jié)奏。短暫地停留是為了更好的決定。

利用抽象分支，是替換新技術(shù)的經(jīng)典方法（長期分支的荒謬性之外）：

• 組件 X 前面放置一個(gè)抽象。

• 組件 Y 做為 X 的替換品，被引入。

• 抽象智能地路由到 X 或 Y。

• X 逐步被廢棄掉。

• X 被移除；或許抽象也被移除了。

有很多次，我都看不到這個(gè)過程能夠順利走完，因?yàn)橐瞥f組件*** 20% 的工作太難了。你簡直想象不到，年復(fù)一年地用多種方式做這項(xiàng)工作有多么痛苦。它減緩了所有工作，還讓士氣消沉。抽象分支屬于優(yōu)秀的模式，他也是我做這種組件替換工作的唯一方式。但是，它需要團(tuán)隊(duì)的完全承諾，即，在既定時(shí)間內(nèi)，淘汰舊組件。

技術(shù)債務(wù)會(huì)殺了你

僅僅因?yàn)槲覀冞@里過多地討論了技術(shù)債務(wù)，并不能為償還技術(shù)債務(wù)提供任何擔(dān)保。有一點(diǎn)是肯定的，任由技術(shù)債務(wù)積壓下去，只會(huì)使其變得無法償還。「先放一放。我們先做其它緊急需求，它被記下來了，我們回頭再搞。」，這話很容易說出口。同時(shí)，它可能算得上明智決定。但是，那些所謂的緊急需求永遠(yuǎn)沒有結(jié)束的那一天。緊急清單只會(huì)越變?cè)介L。

狀況會(huì)惡化下去。據(jù)我經(jīng)驗(yàn)看，當(dāng)技術(shù)債務(wù)積壓增長過于頻繁時(shí)，團(tuán)隊(duì)將趨向于放棄償還，團(tuán)隊(duì)感到失望，開發(fā)人員不能達(dá)到流動(dòng)，業(yè)務(wù)也獲取不到新的價(jià)值。關(guān)于如何避免不可逾越的技術(shù)債務(wù)，我做過一些思考。

一個(gè)良好的開發(fā)團(tuán)隊(duì)，不會(huì)一而再、再而三地以技術(shù)債務(wù)為借口。當(dāng)團(tuán)隊(duì)意識(shí)到，同種技術(shù)債務(wù)重復(fù)出現(xiàn)時(shí)，就必須向前推動(dòng)，并很快將其融入到日常工作中去。

我的同事 Badri 建議，團(tuán)隊(duì)必須就共同承擔(dān)技術(shù)債務(wù)達(dá)成一致。任何人無權(quán)讓代碼庫變得更糟、而讓整個(gè)團(tuán)隊(duì)隨后為此買單。

更重要的是，技術(shù)領(lǐng)導(dǎo)和產(chǎn)品領(lǐng)導(dǎo)需要彼此信任。雙方都不應(yīng)該玩「我說了算」的把戲。好的技術(shù)領(lǐng)導(dǎo)理解業(yè)務(wù)的優(yōu)先級(jí)，好的產(chǎn)品經(jīng)理看重能夠交付的價(jià)值。雙方均需要探討風(fēng)險(xiǎn)、成本和收益。如果你無法交付，你的技術(shù)債務(wù)就轉(zhuǎn)變成了業(yè)務(wù)問題，對(duì)每個(gè)人都沒有好處。

顯然，為了編寫長期存在的代碼，一個(gè)團(tuán)隊(duì)還有大量工作要做：為閱讀代碼的人寫代碼，不要自作聰明，經(jīng)常想想你未來的同事。我樂于聽到你的想法。