準確識別技術債務才是改造遺留系統的破解之道

轉載贊收藏評論

舉報 2022-05-09

掃描,分享朋友圈

大廠的遺留系統一般會呈現什么樣的特點呢？第一是存量代碼規模特別大，其次是技術棧特別全，最后是架構的演進時間長，10 年至 20 年的祖傳遺留系統非常常見。

祖傳代碼

遺留系統的架構通常如上圖所示：它可以完整運行，整個系統功能也比較穩定。然而由于技術棧過時造成演進性不足，文檔過時或丟失導致與真實的系統脫節，當初的設計者可能已經離開公司，或者升遷到管理層，輕易的改動帶來的連鎖反應很容易導致整個系統的不穩定。面對這樣的遺留系統一般人都會比較謹慎，技術人員更愿意重寫而不是做遺留系統的改造。

但從成本上來看改造比推倒重來短期成本要高（分析問題，制定策略），長期成本要低得多（變化及規格丟失導致客戶投訴）?？紤]到風險成本，我更愿意去做遺留系統的改造而非重構。重寫過程中面臨需求的雙重交付壓力，文檔缺失規格很容易丟失，在測試階段僅僅補齊規格就需要很長一段時間，技術人員很容易陷入到技術情結中，重寫前承諾的收益往往很難兌現，更換架構和編程語言極易造成團隊不穩定，架構師通常會選擇他喜歡的語言，程序員通常會選擇他擅長的語言，僅僅選擇語言就是一門很難的功課，通常 App 開發的選擇是 Java、Scala、Go，高性能系統開發選擇是 Rust，C++，而膠水類腳本語言開發選擇 TS/JS、Python、Lua。

如果你是一個信心滿滿的架構師，選擇了更具挑戰的遺留系統改造，動手前你應該知道這個遺留系統有哪些呆賬壞賬，這些欠賬稱為技術債務。你不僅要搞清楚都有哪些債務，還要搞清楚欠債的根因是什么。架構與代碼代表工程師寫的瞬間對架構、代碼、業務、環境的認知，隨著技術進步，環境變化技術債務就自然產生了，這部分債務屬于良性債務，或者說無法避免的債務。另一種債務可能是快速迭代追求商業價值的妥協產物，如果沒有重構的投資，或團隊缺乏重構的基因，就需要要去改進流程和工具。以我的經驗債務的消減需要雷鋒，團隊文化要求不能讓雷鋒吃虧。

不同規模遺留系統的特點

規模系統

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

如果你是一個技術專家，管理 100 個微服務大概 200 萬行規模的代碼。這時你僅靠個人能力和代碼檢視是不夠的。100 個微服務的團隊人數一般是 100+，這樣的團隊規模需要的是一套優秀的實踐體系，從軟件的架構設計（建模，設計與實現一致），到需求分解（并行，Tasking），再到代碼提交（代碼持續集成，小步提交，每日檢視），最后是測試方法（TDD，BDD，統一測試框架）。

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

再往上管理 5000 個左右微服務，這樣的團隊通?？赡軙绲赜?。我并沒有真實地管理過這么大規模的項目，所以我沒有發言權。

不同規模遺留系統的應對策略

小規模策略

高級工程師

我個人認為高級工程師管理一個微服務只要熟讀設計模式，可以熟練地使用，就可以把一個微服務改造得非常好。

微服務的開發，可能連使用復雜設計模式的機會都沒有，在云原生的領域里已經把單體應用的架構模塊設計通過微服務及基礎設施解耦掉了，甚至做到了 Serverless。面向云原生開發你只需要專注于把業務代碼寫出來就可以。

靜態掃描工具可以掃出來爛代碼，因為爛代碼有規則，寫好出好代碼是沒有固定模式的，現階段識別好代碼最靠得住的方案仍然是人工識別。業界比較好的工具如 Codota，它是一款免費 AI 自動補全編碼工具，可以集成在 IDEA 中，輸入字符后它會自動幫你聯想補全最佳代碼片段，還可以片段檢索。另外就是讀一下 Clean Code、Clean Arch、Effective Code、設計模式等書籍，可以幫助你提升自己的代碼品位。

技術負責人

如果管理 10 個服務，怎么樣確保讓這 10 個服務履行你的架構設計意圖呢？我做團隊技術負責人的時候堅持每天做代碼檢視。代碼檢視是一個非常好的手段，誰的代碼是 TDD 的，誰做了重構，誰有想法都是一目了然的。前提是檢視會議不能只是領導在講，開發在開小差的狀態，在我看來代碼檢視是每天的黃金 30 分鐘。

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

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

最后，在檢視中我們可以盡早發現設計方面的問題，選用更合適的設計模式。代碼已經寫完以后才發現設計有問題就晚了，這時技術債務就已經形成了。所以代碼檢視的過程是學習的過程，也是相互促進的過程。我們在代碼檢視中經?？梢园l現一些檢視的意見領袖，這些意見領袖在我們團隊里面就是我們后備的 Tech Lead。

除了檢視，我們在團隊中還落地了一些優秀實踐，比如 TDD。如何落地 TDD？我們要求在新的需求中最好可以用 TDD 的方式，這個是 nice-to-have，并不是 need-to-have，所以在檢視中如果誰用了 TDD 的方式，我們會給予他鼓勵。

這兩年通過微服務火起來的 DDD 炙手可熱，今年我們也搞了一些 DDD 的實踐——Event-Storming 建模、基于 DDD 的微服務實戰項目。DDD 是一個概念，一套理論，如何讓大家在實踐中把 DDD 落到項目中需要有一個 DDD Demo Project，有先鋒團隊愿意去嘗試，我認為這是團隊氛圍好的體現。

百萬級代碼規模策略

技術專家

如果你是一個管理 100 個微服務的技術專家，想要管理這么大的團隊，你要做到前面提到的所有實踐，實踐是累加的過程，理論上來講你無法跳過小團隊管理經驗直接到首席架構師。有一些團隊的 Tech Lead 并不認可 TDD，不認可 DDD，這是很正常。在我們團隊中會尊重不同的 Tech Lead 的選擇，永遠拒絕一刀切。

除此之外，我認為管理這么多微服務比較重要的是 Metrics。比如去度量團隊的架構債務，代碼債務有多少，把債務通過公式轉換成時間，這樣就得到 A 團隊的技術債務是 30 分鐘，B 團隊的技術債務是 3 天。大概有一個 Metrics 的 Dashboard，我們就可以看到它每天的債務是增長的還是燃盡的，如果數據的維度比較多，那么就需要通過一個成熟度評估，比如 Level3，或 3 star 團隊。

另外一個是 Backlog，Backlog 并不是一個 list 來記需要干的事情，我們通常會給團隊投資一個 Backlog 去做重構或寫測試。如果你要求一個團隊或者一個工程師寫完代碼以后必須要帶測試，寫完代碼以后必須要重構，一般來說他不會去做，因為這對他來說沒有收益。我認為重構、寫測試也是編碼，也屬于產出，所以要給團隊一個 Backlog，給團隊一定的比例去做重構和開發者測試。開發者測試包括了 UT、FT、AT 等等，還包括一些性能測試、集成測試。

10 年前，我第一次體驗敏捷，那時我還覺得敏捷是一種管理手段。后來我接觸了一些極限編程的工程實踐和一些優秀的人，和這些人一起工作 1 年后，最終使我認可敏捷。像我司這樣的雙模 IT 企業比較少，所謂雙模就是 IT 加 CT，我的感受是 IT 領域更適合遵循計劃，CT 領域更適合響應變化。

給大家講一個故事，我有一個做硬件的朋友，他每個季度都要出一趟差把他們的設計送到車間去生產出來一批樣機。他每次都非常擔心，如果樣機出現任何設計問題他的麻煩就大了。像這樣的開發模式必須充分設計、充分驗證，充分測試，才能上線。

本文系作者授權數英發表，內容為作者獨立觀點，不代表數英立場。
轉載請在文章開頭和結尾顯眼處標注：作者、出處和鏈接。不按規范轉載侵權必究。