準(zhǔn)確識(shí)別技術(shù)債務(wù)才是改造遺留系統(tǒng)的破解之道丨IDCF

來(lái)源：InfoQ作者：白嗣健，華為 云化平臺(tái)技術(shù)專(zhuān)家，軟件特戰(zhàn)隊(duì)隊(duì)長(zhǎng)，華為人報(bào)戰(zhàn)斗在 0 與 1 的世界作者，管理千萬(wàn)級(jí)代碼規(guī)模行平臺(tái)產(chǎn)品。編輯：支小亞

今天來(lái)聊聊大規(guī)模的遺留系統(tǒng)。大廠(chǎng)的遺留系統(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)致客戶(hù)投訴）。考慮到風(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++，而膠水類(lèi)腳本語(yǔ)言開(kāi)發(fā)選擇 TS/JS、Python、Lua。

如果你是一個(gè)信心滿(mǎn)滿(mǎn)的架構(gòu)師，選擇了更具挑戰(zhàn)的遺留系統(tǒng)改造，動(dòng)手前你應(yīng)該知道這個(gè)遺留系統(tǒng)有哪些呆賬壞賬，這些欠賬稱(chē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ù)專(zhuān)家，管理 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ā)你只需要專(zhuān)注于把業(yè)務(wù)代碼寫(xiě)出來(lái)就可以。

靜態(tài)掃描工具可以?huà)叱鰜?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)?？梢园l(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ù)專(zhuān)家

如果你是一個(gè)管理 100 個(gè)微服務(wù)的技術(shù)專(zhuān)家，想要管理這么大的團(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ē)間去生產(chǎn)出來(lái)一批樣機(jī)。他每次都非常擔(dān)心，如果樣機(jī)出現(xiàn)任何設(shè)計(jì)問(wèn)題他的麻煩就大了。像這樣的開(kāi)發(fā)模式必須充分設(shè)計(jì)、充分驗(yàn)證，充分測(cè)試，才能上線(xiàn)。

CT 領(lǐng)域就更適合敏捷了，尤其是互聯(lián)網(wǎng)。我也曾在互聯(lián)網(wǎng)工作過(guò)，互聯(lián)網(wǎng)的訴求是要快速地試錯(cuò)，允許灰度發(fā)布。反饋好就加大投資，反饋平平就下線(xiàn)。因此軟件領(lǐng)域更適合微服務(wù)，更適合敏捷。

其次就是 CI/CD、DevOps，很多團(tuán)隊(duì)有 CI/CD 流水線(xiàn)，他可以給你展示——看我們的流水線(xiàn)是這樣跑的，但是點(diǎn)進(jìn)去一看就會(huì)發(fā)現(xiàn)有很多問(wèn)題。比如說(shuō)微服務(wù)什么時(shí)候拆？很多人可能會(huì)說(shuō)我們?cè)诮r(shí)候就已經(jīng)拆好了，這是架構(gòu)師分析來(lái)的。多年的工作經(jīng)驗(yàn)告訴我微服務(wù)并不是拆出來(lái)的，而是演進(jìn)來(lái)的。

拆分服務(wù)最佳時(shí)機(jī)我認(rèn)為是在集成的過(guò)程中。一個(gè)服務(wù)持續(xù)集成時(shí)間過(guò)長(zhǎng)會(huì)導(dǎo)致團(tuán)隊(duì)的整體速率變?nèi)?，此時(shí)就需要改進(jìn)了。如果開(kāi)發(fā)人員合一次代碼需要 30 分鐘以上，如果團(tuán)隊(duì)規(guī)模是 Two Pizza，那每個(gè)人集成一次這需要很長(zhǎng)時(shí)間，這可能導(dǎo)致無(wú)法準(zhǔn)時(shí)下班。

此時(shí)通過(guò)一些手段去優(yōu)化測(cè)試、優(yōu)化集成效率仍然不能滿(mǎn)足 30 分鐘以下，就可以分析如何拆分服務(wù)了，然后相應(yīng)地根據(jù)康威定律的需要把這個(gè)團(tuán)隊(duì)進(jìn)行拆分，這是我用來(lái)識(shí)別什么樣的服務(wù)應(yīng)該要被拆分的一種方式。

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

軟件總工

當(dāng)你要改造千萬(wàn)級(jí)的代碼——一般是 2000 萬(wàn)行左右的代碼，這種情況團(tuán)隊(duì)可能都不在一個(gè)地域，如何去管理這么多人、這么多的服務(wù)？如果技術(shù)沒(méi)有管控覆蓋絕大多數(shù)技術(shù)棧，那么難度會(huì)指數(shù)暴增。在這種場(chǎng)景下你身為一個(gè)總工也好高級(jí)技術(shù)專(zhuān)家也好，首先你要構(gòu)建你的通用編程框架，基礎(chǔ)設(shè)施，通用的公共組件以及債務(wù)的識(shí)別能力。

《演進(jìn)式架構(gòu)》里面提到了一個(gè)非常重要的點(diǎn)叫 Fitness Function，這是用于遺傳學(xué)的算法。大家想想如果你開(kāi)了上帝視角，如何確保整個(gè)世界根據(jù)你的想法進(jìn)行迭代演進(jìn)？世界是隨機(jī)的，我們只能定義一些系統(tǒng)性方程，讓適合方程的活下來(lái)，淘汰掉不合格的，這就是優(yōu)勝劣汰。講到這里，如果你可以寫(xiě)一組方程來(lái)落地架構(gòu)和代碼的演進(jìn)意圖，就可以用適應(yīng)性方程來(lái)控制整個(gè)大盤(pán)。

另外一個(gè)是 Clean Architecture，這是 Uncle Bob 的一個(gè)方法論（https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html）。我們的架構(gòu)演進(jìn)參考了 Clean Architecture，但是我們做了一個(gè)變種，更適合我們的 Clean Architecture Plus。

在改造過(guò)程中，架構(gòu)演進(jìn)難免碰到基礎(chǔ)設(shè)施不兼容的場(chǎng)景，如何進(jìn)行架構(gòu)重構(gòu)呢？第一步將基礎(chǔ)設(shè)施比如 MQ、DB、DFS、Cache 等進(jìn)行了基礎(chǔ)設(shè)施的抽象，這一層很薄，但是卻很重要。第二步是 App 開(kāi)發(fā)依賴(lài)新的接口進(jìn)行開(kāi)發(fā)，這樣就做到了應(yīng)用開(kāi)發(fā)與基礎(chǔ)設(shè)施的解耦，由于應(yīng)用不關(guān)心基礎(chǔ)設(shè)施是什么，讓我們服務(wù)更加 Serverless，在編程過(guò)程中也更容易寫(xiě)測(cè)試。第三步是基礎(chǔ)設(shè)施團(tuán)隊(duì)根據(jù) API 去實(shí)現(xiàn)，在架構(gòu)重構(gòu)中難免會(huì)出現(xiàn)更換基礎(chǔ)設(shè)施的情況，對(duì)于應(yīng)用來(lái)說(shuō)不感知，在基礎(chǔ)設(shè)施實(shí)現(xiàn)過(guò)程中去做適配，Bazel 是可以按需構(gòu)建的，整個(gè)過(guò)程中接口作為了契約，通過(guò)契約測(cè)試實(shí)踐進(jìn)行接口及契約管控，契約測(cè)試也根據(jù)現(xiàn)狀進(jìn)行了改造，比如使用 git repo 代替 service broker，開(kāi)發(fā)及構(gòu)建過(guò)程通過(guò) git 稀疏檢出進(jìn)行訪(fǎng)問(wèn)，操作麻煩就統(tǒng)一 CLI 工具集，這樣基礎(chǔ)設(shè)施架構(gòu)和應(yīng)用架構(gòu)滿(mǎn)足了依賴(lài)倒置及權(quán)限分離管控。如果你是一個(gè)善良的架構(gòu)師，編程框架 runtime 的統(tǒng)一也必不可少。

落地實(shí)踐閉坑指南

經(jīng)常有人抱怨 A 技術(shù)不行，B 實(shí)踐不好，在我腦海里就會(huì)浮現(xiàn)出下面這幅圖：

賣(mài)家秀和買(mǎi)家秀

這是典型的“賣(mài)家秀”和“買(mǎi)家秀”。我見(jiàn)過(guò)太多團(tuán)隊(duì)把敏捷落地成了管理手段，把檢視變成了批判大會(huì)，與其說(shuō)沒(méi)有學(xué)到精髓，不如說(shuō)他們偷換了概念，我的經(jīng)驗(yàn)是你想學(xué)會(huì)一個(gè)東西，最好最快的方式就是和他們工作過(guò)。

敏捷的精髓是什么？我認(rèn)為敏捷的精髓就是敏捷宣言里面講的 4 條價(jià)值觀。在學(xué)敏捷的過(guò)程中一不小心就會(huì)學(xué)成買(mǎi)家秀，然后大罵這個(gè)理論是有缺陷的！理論是不對(duì)的！比如現(xiàn)在很多人在討論是不是 TDD 已死？是不是設(shè)計(jì)已死？我仍然認(rèn)為任何一個(gè)東西都有人可以把它玩得非常好，任何一個(gè)再好的東西都有人會(huì)把它執(zhí)行得非常地偏，非常地差，以至于整個(gè)團(tuán)隊(duì)的動(dòng)作變形。

有很多團(tuán)隊(duì)負(fù)責(zé)人給我講敏捷就是騙人的，覺(jué)得敏捷就是一些流程的動(dòng)作，敏捷在遺留系統(tǒng)改造中起不到任何作用，僅僅是一些管理的手段。很多人覺(jué)得代碼檢視是一件浪費(fèi)時(shí)間的事情，怎么可以每天做呢？我們把代碼提交給 Committer 去 Review 就可以了。這些東西見(jiàn)仁見(jiàn)智，只有你去優(yōu)秀的團(tuán)隊(duì)踐行過(guò)你才能真正體會(huì)到這里面的精髓是什么，你才能把檢視做好。

我認(rèn)為心得體會(huì)和經(jīng)驗(yàn)才更有借鑒價(jià)值而非實(shí)踐本身。優(yōu)秀實(shí)踐是如何誕生的呢？大都是把一個(gè)實(shí)踐當(dāng)做模板，結(jié)合團(tuán)隊(duì)的認(rèn)知數(shù)據(jù)和現(xiàn)狀數(shù)據(jù)，經(jīng)過(guò)無(wú)數(shù)次迭代，參考會(huì)議上大家的改良意見(jiàn)從而形成優(yōu)秀實(shí)踐。軟件開(kāi)發(fā)之所以無(wú)法被 AI 完全替代（20 年內(nèi)），恰恰因?yàn)闆](méi)有銀彈。

總? ? 結(jié)

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

• 代碼量特別多

• 技術(shù)棧特別全

• 架構(gòu)的演進(jìn)時(shí)間比較長(zhǎng)

2. 應(yīng)對(duì)策略

• 小規(guī)?！熳x設(shè)計(jì)模式，熟練地使用、代碼檢視

• 百萬(wàn)級(jí)代碼規(guī)模——Metrics、度量團(tuán)隊(duì)的架構(gòu)債務(wù)、敏捷

• 千萬(wàn)級(jí)代碼規(guī)?！y(tǒng)計(jì)債務(wù)、Clean Code、CleanArchitecture

• 學(xué)到敏捷的精髓

2022年首場(chǎng)將在美麗的海濱城市-大連舉辦，8月6-7日，36小時(shí)內(nèi)從0到1打造并發(fā)布一款產(chǎn)品。

企業(yè)組隊(duì)參賽&個(gè)人參賽均可，趕緊上車(chē)~??