大廠的遺留系統(tǒng)一般會(huì)呈現(xiàn)什么樣的特點(diǎn)呢？第一是存量代碼規(guī)模特別大，其次是技術(shù)棧特別全，最后是架構(gòu)的演進(jìn)時(shí)間長(zhǎng)，10 年至 20 年的祖?zhèn)鬟z留系統(tǒng)非常常見(jiàn)。

祖?zhèn)鞔a

遺留系統(tǒng)的架構(gòu)通常如上圖所示：它可以完整運(yùn)行，整個(gè)系統(tǒng)功能也比較穩(wěn)定。然而由于技術(shù)棧過(guò)時(shí)造成演進(jìn)性不足，文檔過(guò)時(shí)或丟失導(dǎo)致與真實(shí)的系統(tǒng)脫節(jié)，當(dāng)初的設(shè)計(jì)者可能已經(jīng)離開(kāi)公司，或者升遷到管理層，輕易的改動(dòng)帶來(lái)的連鎖反應(yīng)很容易導(dǎo)致整個(gè)系統(tǒng)的不穩(wěn)定。面對(duì)這樣的遺留系統(tǒng)一般人都會(huì)比較謹(jǐn)慎，技術(shù)人員更愿意重寫(xiě)而不是做遺留系統(tǒng)的改造。

但從成本上來(lái)看改造比推倒重來(lái)短期成本要高（分析問(wèn)題，制定策略），長(zhǎng)期成本要低得多（變化及規(guī)格丟失導(dǎo)致客戶投訴）?？紤]到風(fēng)險(xiǎn)成本，我更愿意去做遺留系統(tǒng)的改造而非重構(gòu)。重寫(xiě)過(guò)程中面臨需求的雙重交付壓力，文檔缺失規(guī)格很容易丟失，在測(cè)試階段僅僅補(bǔ)齊規(guī)格就需要很長(zhǎng)一段時(shí)間，技術(shù)人員很容易陷入到技術(shù)情結(jié)中，重寫(xiě)前承諾的收益往往很難兌現(xiàn)，更換架構(gòu)和編程語(yǔ)言極易造成團(tuán)隊(duì)不穩(wěn)定，架構(gòu)師通常會(huì)選擇他喜歡的語(yǔ)言，程序員通常會(huì)選擇他擅長(zhǎng)的語(yǔ)言，僅僅選擇語(yǔ)言就是一門(mén)很難的功課，通常 App 開(kāi)發(fā)的選擇是 Java、Scala、Go，高性能系統(tǒng)開(kāi)發(fā)選擇是 Rust，C++，而膠水類腳本語(yǔ)言開(kāi)發(fā)選擇 TS/JS、Python、Lua。

如果你是一個(gè)信心滿滿的架構(gòu)師，選擇了更具挑戰(zhàn)的遺留系統(tǒng)改造，動(dòng)手前你應(yīng)該知道這個(gè)遺留系統(tǒng)有哪些呆賬壞賬，這些欠賬稱為技術(shù)債務(wù)。你不僅要搞清楚都有哪些債務(wù)，還要搞清楚欠債的根因是什么。架構(gòu)與代碼代表工程師寫(xiě)的瞬間對(duì)架構(gòu)、代碼、業(yè)務(wù)、環(huán)境的認(rèn)知，隨著技術(shù)進(jìn)步，環(huán)境變化技術(shù)債務(wù)就自然產(chǎn)生了，這部分債務(wù)屬于良性債務(wù)，或者說(shuō)無(wú)法避免的債務(wù)。另一種債務(wù)可能是快速迭代追求商業(yè)價(jià)值的妥協(xié)產(chǎn)物，如果沒(méi)有重構(gòu)的投資，或團(tuán)隊(duì)缺乏重構(gòu)的基因，就需要要去改進(jìn)流程和工具。以我的經(jīng)驗(yàn)債務(wù)的消減需要雷鋒，團(tuán)隊(duì)文化要求不能讓雷鋒吃虧。

不同規(guī)模遺留系統(tǒng)的特點(diǎn)

規(guī)模系統(tǒng)

管理的規(guī)模不同，面臨的問(wèn)題就不一樣，面臨的問(wèn)題不一樣，所采用的方法就不一樣。如果你管理一個(gè)代碼規(guī)模 20K 左右的微服務(wù)，相信你通過(guò)個(gè)人能力很快可以將其改造為最佳狀態(tài)。如果你是一個(gè)技術(shù)負(fù)責(zé)人，管理 10 個(gè)微服務(wù)約 200K 代碼，依靠個(gè)人能力很難將其改造為最佳狀態(tài)。你需要想辦法在團(tuán)隊(duì)中建立起某個(gè)機(jī)制，比如每日代碼集體檢視，它解決了日常的管理、能力提升、review 設(shè)計(jì)思路，每一個(gè) commit等問(wèn)題，避免了錯(cuò)誤的設(shè)計(jì)落入版本的尷尬場(chǎng)面。那些在檢視中投入度比較高，經(jīng)常能夠給別人提出建設(shè)性建議（檢視意見(jiàn)）的人就是可以重點(diǎn)培養(yǎng)的下一任的 Tech Lead，相信我，集體檢視是小團(tuán)隊(duì)最有效的管理方式。

如果你是一個(gè)技術(shù)專家，管理 100 個(gè)微服務(wù)大概 200 萬(wàn)行規(guī)模的代碼。這時(shí)你僅靠個(gè)人能力和代碼檢視是不夠的 。100 個(gè)微服務(wù)的團(tuán)隊(duì)人數(shù)一般是 100+，這樣的團(tuán)隊(duì)規(guī)模需要的是一套優(yōu)秀的實(shí)踐體系，從軟件的架構(gòu)設(shè)計(jì)（建模，設(shè)計(jì)與實(shí)現(xiàn)一致），到需求分解（并行，Tasking），再到代碼提交（代碼持續(xù)集成，小步提交，每日檢視），最后是測(cè)試方法（TDD，BDD，統(tǒng)一測(cè)試框架）。

不過(guò)我想重點(diǎn)談一談如果管理 500 個(gè)微服務(wù)，大概千萬(wàn)級(jí)代碼規(guī)模。想要管理這樣一個(gè)組織，讓這些服務(wù)都按照你想要的方式去進(jìn)行演進(jìn)，就要結(jié)合上面提到的所有實(shí)踐，包括個(gè)人的能力、團(tuán)隊(duì)的氛圍、優(yōu)秀實(shí)踐，還要多加上一些方法論的應(yīng)用。其難點(diǎn)在于不能生搬硬套，要為團(tuán)隊(duì)量身打造，通過(guò)影響力形成團(tuán)隊(duì)共識(shí)，制定落地策略，下一篇會(huì)舉例講解。

再往上管理 5000 個(gè)左右微服務(wù)，這樣的團(tuán)隊(duì)通?？赡軙?huì)跨地域。我并沒(méi)有真實(shí)地管理過(guò)這么大規(guī)模的項(xiàng)目，所以我沒(méi)有發(fā)言權(quán)。

不同規(guī)模遺留系統(tǒng)的應(yīng)對(duì)策略

小規(guī)模策略

高級(jí)工程師

我個(gè)人認(rèn)為高級(jí)工程師管理一個(gè)微服務(wù)只要熟讀設(shè)計(jì)模式，可以熟練地使用，就可以把一個(gè)微服務(wù)改造得非常好。

微服務(wù)的開(kāi)發(fā)，可能連使用復(fù)雜設(shè)計(jì)模式的機(jī)會(huì)都沒(méi)有，在云原生的領(lǐng)域里已經(jīng)把單體應(yīng)用的架構(gòu)模塊設(shè)計(jì)通過(guò)微服務(wù)及基礎(chǔ)設(shè)施解耦掉了，甚至做到了 Serverless。面向云原生開(kāi)發(fā)你只需要專注于把業(yè)務(wù)代碼寫(xiě)出來(lái)就可以。

靜態(tài)掃描工具可以掃出來(lái)爛代碼，因?yàn)闋€代碼有規(guī)則，寫(xiě)好出好代碼是沒(méi)有固定模式的，現(xiàn)階段識(shí)別好代碼最靠得住的方案仍然是人工識(shí)別。業(yè)界比較好的工具如 Codota，它是一款免費(fèi) AI 自動(dòng)補(bǔ)全編碼工具，可以集成在 IDEA 中，輸入字符后它會(huì)自動(dòng)幫你聯(lián)想補(bǔ)全最佳代碼片段，還可以片段檢索。另外就是讀一下 Clean Code、Clean Arch、Effective Code、設(shè)計(jì)模式等書(shū)籍，可以幫助你提升自己的代碼品位。

技術(shù)負(fù)責(zé)人

如果管理 10 個(gè)服務(wù)，怎么樣確保讓這 10 個(gè)服務(wù)履行你的架構(gòu)設(shè)計(jì)意圖呢？我做團(tuán)隊(duì)技術(shù)負(fù)責(zé)人的時(shí)候堅(jiān)持每天做代碼檢視。代碼檢視是一個(gè)非常好的手段，誰(shuí)的代碼是 TDD 的，誰(shuí)做了重構(gòu)，誰(shuí)有想法都是一目了然的。前提是檢視會(huì)議不能只是領(lǐng)導(dǎo)在講，開(kāi)發(fā)在開(kāi)小差的狀態(tài)，在我看來(lái)代碼檢視是每天的黃金 30 分鐘。

代碼檢視實(shí)際上有很多優(yōu)秀實(shí)踐，比如檢視前要求每位同學(xué)檢視代碼前先自己過(guò)一遍，想想怎么講，要有邏輯，要容易讓別人聽(tīng)懂，這樣才能縮減檢視時(shí)間。有時(shí)候上午寫(xiě)的代碼，到下午就忘了今天上午我為什么這樣想這樣寫(xiě)。

其次，我們對(duì)檢視的時(shí)間有要求，如果你能堅(jiān)持每天檢視，每天檢視時(shí)間一般不會(huì)超過(guò)半個(gè)小時(shí)。檢視的第一步就是把 Commit、Comments 過(guò)一下，快速地讓別人知道我今天干了什么事情。接著快速地瀏覽每一行代碼，在瀏覽過(guò)程中如果遇到一些常見(jiàn)的問(wèn)題和共性的問(wèn)題，我們可以在檢視中講一下。

最后，在檢視中我們可以盡早發(fā)現(xiàn)設(shè)計(jì)方面的問(wèn)題，選用更合適的設(shè)計(jì)模式。代碼已經(jīng)寫(xiě)完以后才發(fā)現(xiàn)設(shè)計(jì)有問(wèn)題就晚了，這時(shí)技術(shù)債務(wù)就已經(jīng)形成了。所以代碼檢視的過(guò)程是學(xué)習(xí)的過(guò)程，也是相互促進(jìn)的過(guò)程。我們?cè)诖a檢視中經(jīng)常可以發(fā)現(xiàn)一些檢視的意見(jiàn)領(lǐng)袖，這些意見(jiàn)領(lǐng)袖在我們團(tuán)隊(duì)里面就是我們后備的 Tech Lead。

除了檢視，我們?cè)趫F(tuán)隊(duì)中還落地了一些優(yōu)秀實(shí)踐，比如 TDD。如何落地 TDD？我們要求在新的需求中最好可以用 TDD 的方式，這個(gè)是 nice-to-have，并不是 need-to-have，所以在檢視中如果誰(shuí)用了 TDD 的方式，我們會(huì)給予他鼓勵(lì)。

這兩年通過(guò)微服務(wù)火起來(lái)的 DDD 炙手可熱，今年我們也搞了一些 DDD 的實(shí)踐——Event-Storming 建模、基于 DDD 的微服務(wù)實(shí)戰(zhàn)項(xiàng)目。DDD 是一個(gè)概念，一套理論，如何讓大家在實(shí)踐中把 DDD 落到項(xiàng)目中需要有一個(gè) DDD Demo Project，有先鋒團(tuán)隊(duì)愿意去嘗試，我認(rèn)為這是團(tuán)隊(duì)氛圍好的體現(xiàn)。

百萬(wàn)級(jí)代碼規(guī)模策略

技術(shù)專家

如果你是一個(gè)管理 100 個(gè)微服務(wù)的技術(shù)專家，想要管理這么大的團(tuán)隊(duì)，你要做到前面提到的所有實(shí)踐，實(shí)踐是累加的過(guò)程，理論上來(lái)講你無(wú)法跳過(guò)小團(tuán)隊(duì)管理經(jīng)驗(yàn)直接到首席架構(gòu)師。有一些團(tuán)隊(duì)的 Tech Lead 并不認(rèn)可 TDD，不認(rèn)可 DDD，這是很正常。在我們團(tuán)隊(duì)中會(huì)尊重不同的 Tech Lead 的選擇，永遠(yuǎn)拒絕一刀切。

除此之外，我認(rèn)為管理這么多微服務(wù)比較重要的是 Metrics。比如去度量團(tuán)隊(duì)的架構(gòu)債務(wù)，代碼債務(wù)有多少，把債務(wù)通過(guò)公式轉(zhuǎn)換成時(shí)間，這樣就得到 A 團(tuán)隊(duì)的技術(shù)債務(wù)是 30 分鐘，B 團(tuán)隊(duì)的技術(shù)債務(wù)是 3 天。大概有一個(gè) Metrics 的 Dashboard，我們就可以看到它每天的債務(wù)是增長(zhǎng)的還是燃盡的，如果數(shù)據(jù)的維度比較多，那么就需要通過(guò)一個(gè)成熟度評(píng)估，比如 Level3，或 3 star 團(tuán)隊(duì)。

另外一個(gè)是 Backlog，Backlog 并不是一個(gè) list 來(lái)記需要干的事情，我們通常會(huì)給團(tuán)隊(duì)投資一個(gè) Backlog 去做重構(gòu)或?qū)憸y(cè)試。如果你要求一個(gè)團(tuán)隊(duì)或者一個(gè)工程師寫(xiě)完代碼以后必須要帶測(cè)試，寫(xiě)完代碼以后必須要重構(gòu)，一般來(lái)說(shuō)他不會(huì)去做，因?yàn)檫@對(duì)他來(lái)說(shuō)沒(méi)有收益。我認(rèn)為重構(gòu)、寫(xiě)測(cè)試也是編碼，也屬于產(chǎn)出，所以要給團(tuán)隊(duì)一個(gè) Backlog，給團(tuán)隊(duì)一定的比例去做重構(gòu)和開(kāi)發(fā)者測(cè)試。開(kāi)發(fā)者測(cè)試包括了 UT、FT、AT 等等，還包括一些性能測(cè)試、集成測(cè)試。

10 年前，我第一次體驗(yàn)敏捷，那時(shí)我還覺(jué)得敏捷是一種管理手段。后來(lái)我接觸了一些極限編程的工程實(shí)踐和一些優(yōu)秀的人，和這些人一起工作 1 年后，最終使我認(rèn)可敏捷。像我司這樣的雙模 IT 企業(yè)比較少，所謂雙模就是 IT 加 CT，我的感受是 IT 領(lǐng)域更適合遵循計(jì)劃，CT 領(lǐng)域更適合響應(yīng)變化。

給大家講一個(gè)故事，我有一個(gè)做硬件的朋友，他每個(gè)季度都要出一趟差把他們的設(shè)計(jì)送到車間去生產(chǎn)出來(lái)一批樣機(jī)。他每次都非常擔(dān)心，如果樣機(jī)出現(xiàn)任何設(shè)計(jì)問(wèn)題他的麻煩就大了。像這樣的開(kāi)發(fā)模式必須充分設(shè)計(jì)、充分驗(yàn)證，充分測(cè)試，才能上線。