上個月我們終于把內部代號為T3Code的技術專項正式關單了。這個代號沒什么玄機就是今年團隊排到的第三個技術專項順手用來給一批工單做前綴。但整個周期走下來它實際承擔的分量比代號重得多既是一次對核心業(yè)務系統(tǒng)的架構升級也是一次對存量代碼的全面治理還是一次團隊協(xié)作方式的翻新。做這個項目的起因很現(xiàn)實業(yè)務迭代速度上來了需求排期越來越緊可每次改代碼都像在雷區(qū)里走路。改一個訂單狀態(tài)流轉要手動翻四五個配置點新同學入職三周還在靠注釋猜業(yè)務邏輯每次發(fā)布日研發(fā)、測試、運維一起盯著灰度日志像拆彈。我們心里都清楚系統(tǒng)不是一天爛掉的但誰也不想當那個在高速路上換輪胎的人。直到年初一次線上故障根因定位花了兩天最后發(fā)現(xiàn)是五年前加的一段老邏輯在特定條件下覆蓋了新配置。那次之后立項申請一周內就批下來了。這篇文章算是一份完整的復盤記錄把我們從立項、盤點、分層改造到上線踩坑的完整鏈路寫出來。如果你也在帶一個體量不小、歷史包袱很重的業(yè)務系統(tǒng)或者正打算發(fā)起一場代碼治理/架構升級可以參考我們的打法與教訓。1. 為什么系統(tǒng)會走到改不動、不敢改這一步T3Code立項前的問題拆解立項之前我們花了整整一周做問題梳理。很多團隊一談重構就想著推倒重來但其實大部分系統(tǒng)根本不需要重寫需要的是把一個已經(jīng)失去約束力的代碼庫重新管起來。我們先用數(shù)據(jù)說話把不舒服變成可量化的問題。1.1 三個真實痛點耦合、無測試、變更不可見第一個痛點是耦合。訂單模塊看起來是一個完整模塊實際上內部通過靜態(tài)方法、共享工具類、全局配置中心跟十幾個模塊糾纏在一起。我們做過一次粗糙的依賴掃描訂單模塊直接間接引用的類超過兩千個其中三分之一屬于其他業(yè)務模塊。這意味著改訂單模塊的任何一個公共方法影響范圍都無法預估。第二個痛點是沒有測試。核心模塊的單元測試覆蓋率長期停留在個位數(shù)集成測試幾乎為零。不是大家不想寫是系統(tǒng)根本沒按可測試的方式設計數(shù)據(jù)庫連接直接散落在業(yè)務代碼里外部接口調用寫死在靜態(tài)方法中想 mock 都無從下手。測試缺失帶來的直接后果是任何一次重構都沒有安全網(wǎng)誰也不敢動老代碼。第三個痛點更隱蔽變更的不可見性。同一個業(yè)務動作可能在接口層做一次校驗在 service 層做一次狀態(tài)流轉在 DAO 層又做一次數(shù)據(jù)拼裝甚至還有定時任務里補一段歷史數(shù)據(jù)修復邏輯。想要完整追蹤一個字段從進入到落庫的生命周期得順著調用鏈跳七八個類。這種代碼更像補丁疊補丁而不是一個清晰的業(yè)務表達。1.2 立項目標不是重構是止血 分層 自動化基于這三個痛點我們給 T3Code 定了三個核心目標每個目標都有驗收標準目標具體含義驗收標準止血先解決最容易引發(fā)線上故障的耦合點核心模塊的隱性依賴數(shù)量下降 80%分層建立清晰的架構邊界讓依賴方向可管理新代碼必須遵循分層約束違反即構建失敗自動化用測試和流水線替代人工檢查核心模塊覆蓋率提升到 60%發(fā)布支持一鍵回滾我還特別加了一條不做什么清單不搞微服務拆分不換編程語言不把前端一起重寫。原因很簡單一次只解決一個主要矛盾。微服務拆分聽起來高級但在業(yè)務邊界都沒理清楚的階段貿然拆只會把進程內的耦合變成跨服務的網(wǎng)絡調用問題更麻煩。這個決定后來被證明非常關鍵它讓我們把全部精力放在代碼結構本身而不是被分布式帶來的新問題牽著走。1.3 定項目代號的一個小經(jīng)驗T3Code 這個代號是在排期會上隨手定的。我的習慣是給技術專項起個簡短、可復用的代號后續(xù)所有相關的分支名、工單前綴、文檔目錄都用它。這樣做的好處是幾個月后想回顧整個項目的全貌只要搜這個代號就能把所有碎片拼起來。比用重構二期這種模糊叫法好用得多。2. 動手之前先把家底盤清楚真實調用關系、代碼資產(chǎn)與技術選型很多項目失敗死在第一步還沒搞清楚現(xiàn)狀就開干。我們用了接近三周做現(xiàn)狀盤點這一段急不得盤點質量直接決定后面的改造順序和風險評估。2.1 畫出真實的調用關系而不是嘴上說的架構圖我們做的第一件事是靜態(tài)依賴掃描。用工具掃描全部代碼生成類級別和模塊級別的依賴圖。結果跟想象中差別很大架構文檔里畫的訂單模塊依賴庫存模塊是一對一關系實際代碼里訂單模塊還悄悄依賴了用戶模塊的私用工具類、支付模塊的枚舉定義、甚至營銷模塊的緩存 key 常量。很多依賴都是歷史上順手拿過來用累積起來的。我們把這些意外依賴全部記錄下來按兩個維度打標依賴的深度直接還是傳遞和依賴的必要性合理還是歷史遺留。這一步做完心里基本有數(shù)了大概 30% 的跨模塊依賴屬于明顯的路走偏了應該通過接口隔離另外一部分雖然繞但還有歷史原因需要先封裝再逐步收斂。2.2 熱點代碼與廢代碼改造順序的依據(jù)除了依賴關系我們還用動態(tài)鏈路跟蹤梳理了線上熱點。哪個接口調用量最大、哪個方法執(zhí)行時間最長、哪個存儲過程還在被凌晨定時任務依賴這些數(shù)據(jù)直接決定改造優(yōu)先級。有意思的是我們同時發(fā)現(xiàn)了不少僵尸代碼從上線就沒被調用過的控制器、被注釋掉的配置、只在測試環(huán)境生效的開關。這部分代碼混在主干里嚴重干擾了代碼閱讀。T3Code 期間我們順手清了將近兩萬行此類代碼讓整個代碼庫的可讀性提升了一個檔次。2.3 分層決策為什么選三層 防腐層而不是微服務技術選型階段我們內部有過一次很激烈的討論。一部分同學主張借這個機會直接上微服務另一部分包括我主張先做模塊化分層。最終定下來的是邏輯上采用經(jīng)典的三層結構接口層、應用層、領域層依賴方向必須從上往下跨模塊交互全部走接口不允許直接訪問對方的內部實現(xiàn)類。沒有選微服務的核心原因有三一是團隊規(guī)模不支持總共十幾個后端拆出五六個服務后每個服務連一個完整負責人都不夠二是基礎設施沒準備好服務發(fā)現(xiàn)、鏈路追蹤、分布式事務這些底座都還是薄弱項三是業(yè)務邊界本身模糊強行微服務只會把模糊邊界變成網(wǎng)絡開銷。而模塊分層是在同一個代碼庫內解決依賴問題部署方式暫時不變風險要低一個數(shù)量級。2.4 防腐層設計讓老代碼和新代碼能共存增量改造期間老代碼和新代碼必然要共存一段時間。為了避免新寫的代碼被老系統(tǒng)的壞味道二次污染我們在關鍵邊界上加了防腐層。這個概念不復雜本質上就是二十行代碼的事老系統(tǒng)對外提供的任何數(shù)據(jù)都必須經(jīng)過防腐層轉換成新架構里定義的領域模型再進入新代碼。舉個例子老訂單模塊返回的是一個大而全的 OrderDTO二十多個字段帶著各種歷史含義。新代碼里我們定義了 OrderSummary只保留新業(yè)務需要的幾個字段。轉換邏輯統(tǒng)一收口在防腐層里這樣新代碼永遠不會被老模型的臟數(shù)據(jù)帶偏。防腐層還能幫我們逐步收斂當某個老模型在防腐層里被引用的次數(shù)降為零就可以安心刪除。3. 改造路線圖用絞殺者模式讓老代碼體面退休T3Code 最核心的實施策略是采用增量式改造業(yè)內通常叫絞殺者模式或絞殺者植物模式。思路很簡單不試圖一次性替換整個系統(tǒng)而是圍繞老系統(tǒng)一點點生長出新結構每完成一塊就把老的那塊絞殺掉直到老系統(tǒng)徹底退休。3.1 為什么拒絕推倒重來我們很清楚推倒重寫是最危險的選項。業(yè)務系統(tǒng)里沉淀了大量隱性規(guī)則某個狀態(tài)為什么不能從 A 直接到 C某個金額為什么要做兩次精度處理這些規(guī)則文檔里沒寫全只存在于代碼細節(jié)和運維同學的腦子里。真要推倒重來哪怕需求評審做得再細也一定會漏掉一批邊界行為上線就是故障。增量改造的好處是每一塊改造都有明確邊界改造期間老邏輯還在線上運行就算新代碼出了偏差還能隨時切回老鏈路。風險被切成小塊逐一消化而不是攢一次大的爆炸。3.2 第一批改造對象怎么選評估矩陣改造順序很講究。我們建了一個評估矩陣給每個候選模塊打分維度包括業(yè)務重要性、調用熱度、耦合程度、可測試性、團隊熟悉度?？偡衷礁咴絻?yōu)先處理。最終第一批選了三個模塊用戶通知中心、訂單查詢、對賬文件生成。它們的共同點是業(yè)務邏輯相對獨立對外接口清晰不涉及太復雜的事務邊界而且測試同學手上正好有現(xiàn)成的驗證用例。低風險、高收益、好驗證這三條是第一批改造模塊的黃金標準。反過來我們刻意沒碰訂單狀態(tài)機。那個模塊是所有交易的核心行為規(guī)則極其復雜而且改動它會影響十幾個下游系統(tǒng)。它被排到第三批等工具鏈和團隊信心都成熟了再動。3.3 特征測試先給老代碼拍一張行為快照改造老代碼最怕的一件事是老代碼的行為可能是錯的但它錯得有歷史合理性。比如某個接口對非法參數(shù)的處理方式是返回 null這從編碼規(guī)范角度是錯的可如果上游依賴了這個 null 來做空判斷你改成拋異常就是把線上搞炸。解決辦法是特征測試也叫黃金主測試。做法很簡單在改造之前先給老模塊寫一批測試輸入一組真實歷史數(shù)據(jù)斷言輸出結果與老代碼完全一致。這些測試不是為了驗證正確性而是把現(xiàn)狀行為固化下來作為后續(xù)改造的對照基準。這批測試我們寫了大概兩個星期過程很枯燥但回報巨大。在原模塊改造上線后我們直接在新實現(xiàn)上跑特征測試一次就跑出了七處行為差異——全是老代碼里隱藏的特殊分支比如當商品類型為虛擬商品時運費模板字段為 null 但金額必須為 0這類寫都沒寫進文檔的規(guī)則。沒有這層保險這七處差異上線后大概率就是七次線上事故。3.4 遷移七步法從搭腳手架到清理老代碼每個模塊的遷移我們都執(zhí)行同樣的七步流程這套流程后來沉淀成團隊的標準動作搭框架在主干上新建模塊目錄按三層結構建包配好依賴約束規(guī)則。建防腐層定義老模塊與新模塊之間的轉換接口兩邊互不感知對方內部實現(xiàn)。遷移邏輯按業(yè)務用例逐個遷移每遷移一個用例就跑一遍對應特征測試。并行運行新模塊與老模塊同時上線通過開關控制流量走哪條鏈路。灰度放量先讓 1% 流量走新實現(xiàn)觀察日志與錯誤率逐步提升到 10%、50%、100%。穩(wěn)定觀察全量后保持雙寫或并行狀態(tài)至少一個完整業(yè)務周期我們定的是兩周。清理老代碼確認新實現(xiàn)穩(wěn)定刪除老實現(xiàn)與相關配置把特征測試升級為正式回歸測試。這套流程的關鍵是每一小步都可回滾?；叶确帕侩A段一旦發(fā)現(xiàn)異常把開關翻回去就行不需要發(fā)版、不需要回滾數(shù)據(jù)庫整個過程控制在分鐘級。4. 實測中的意外比預期多花兩倍時間的三個坑計劃歸計劃T3Code 實際推進中還是踩了不少坑。挑三個最具代表性的寫在這里它們都不是什么高深的技術難題恰恰是項目管理中最容易被忽略的細節(jié)。4.1 第一個坑全局靜態(tài)狀態(tài)像隱形的鬼魂我們第一個改造的模塊是用戶通知中心邏輯不復雜接口也就五六個。特征測試也寫了一輪感覺挺穩(wěn)。結果灰度到 30% 流量時收到告警通知發(fā)送成功率下降。排查鏈路是這樣的先看新實現(xiàn)日志發(fā)現(xiàn)部分通知發(fā)送任務拋了空指針異常信息指向一個用戶偏好配置對象。繼續(xù)追蹤發(fā)現(xiàn)這個偏好配置是通過一個全局靜態(tài)方法加載的而這個靜態(tài)方法在每次請求時會被老代碼的某個攔截器順便重置。我們的新代碼讀取配置的時間點在重置之后于是拿到的全是 null。這個問題的根源是隱式依賴新模塊看似只依賴自己的代碼實際運行時卻被老系統(tǒng)的全局狀態(tài)綁架了。我們的解法分兩步第一步立刻在接入層加一層顯式依賴注入把偏好配置的讀取時機提前到老攔截器執(zhí)行之前第二步在代碼掃描規(guī)則里加了一條禁令——新模塊代碼不允許直接訪問任何 static 非 final 的全局容器。這個坑給我們的教訓是代碼結構和運行時行為是兩回事。依賴掃描只能看到顯式引用顯式的坑一抓一個準但靜態(tài)變量、ThreadLocal、全局單例這種隱式狀態(tài)比顯式依賴危險十倍。排查隱式依賴最有效的辦法不是讀代碼而是看灰度期間線上的完整調用鏈日志。4.2 第二個坑特征測試只錄了正常動作漏了異常分支特征測試幫我們兜住了大量行為差異但有一類差異它沒兜住——異常路徑。我們當時的測試數(shù)據(jù)主要來自線上正常請求的采樣天然缺少異常分支的數(shù)據(jù)。直到全量上線后的第三天財務同學反饋某類退款訂單在賬單文件里缺少金額字段。查下來發(fā)現(xiàn)老代碼在處理訂單已部分退款這種情況時有一個隱晦的補位邏輯如果主金額字段為空會把最近一筆退款金額寫入賬單的備注字段。這個邏輯非常冷門只在少量歷史訂單上觸發(fā)我們的特征測試數(shù)據(jù)集里恰好沒有這類數(shù)據(jù)。這個坑的修復本身很簡單補上邏輯就行。但暴露了一個方法論問題特征測試的樣本質量決定了行為快照的完整度。后來我們改進了測試數(shù)據(jù)采集方式不只采樣正常流量還專門從歷史工單、線上異常日志、客服反饋表里挖掘邊界輸入把低頻但真實的分支補進數(shù)據(jù)集。4.3 第三個坑切換流量的回滾預案差點變成滾不回去第二個模塊訂單查詢改造時我們在設計階段就考慮了數(shù)據(jù)兼容新代碼讀的是一張新表老代碼讀的是老表兩邊通過一個同步任務保持數(shù)據(jù)一致。結果灰度期間一切正常全量兩周后準備清理老代碼時發(fā)現(xiàn)一個嚴重問題新表的數(shù)據(jù)只有全量上線后的增量歷史數(shù)據(jù)靠同步任務回填但回填任務因為源表一個字段類型不匹配凌晨跑批直接失敗了而且失敗后沒有告警一直在靜默重試。這意味著如果此時回滾老代碼用戶查詢歷史訂單時會發(fā)現(xiàn)數(shù)據(jù)不完整。我們的回滾預案只準備了流量切回去沒考慮數(shù)據(jù)也得跟著切回去。修復方案很樸素重新修正回填任務的類型映射全量重跑一遍數(shù)據(jù)補齊后才繼續(xù)清理動作。這個坑給我們的教訓是任何涉及數(shù)據(jù)遷移的改造回滾預案必須同時覆蓋應用層回滾和數(shù)據(jù)層回滾。永久性的數(shù)據(jù)變更尤其要謹慎最好在切換前就搞定完整回填而不是把回填拖到切換之后。4.4 踩坑之后的復盤機制這三個坑暴露之后我們調整了項目節(jié)奏每次灰度放量前增加一次隱式變量排查清單評審每次全量切換前增加一次數(shù)據(jù)完整性演練。額外付出的時間成本不多但直接把后期返工量砍掉了一大半。我把這三個坑整理成了表格貼在了團隊 wiki 上作為后續(xù)所有技術改造項目的默認檢查項坑點觸發(fā)條件攔截手段全局靜態(tài)狀態(tài)干擾新模塊與老模塊共享進程灰度期間全鏈路日志分析禁止 static 可變容器特征測試樣本覆蓋不全只采樣正常流量結合工單和異常日志補充邊界樣本數(shù)據(jù)回填沉默失敗同步任務無告警回填任務必須加成功率和時延告警5. 收官復盤T3Code 給團隊留下了哪些長期資產(chǎn)項目關單不代表一切結束。我們花了額外一周做完整復盤把數(shù)據(jù)、流程、團隊變化都梳理了一遍。這部分我覺得比單點的技術方案更重要因為技術方案能解決眼前問題而流程和認知的升級才是長期資產(chǎn)。5.1 硬指標變化效率、質量與可維護性直接看數(shù)據(jù)。改造涉及的核心模塊一共四個覆蓋了全年 70% 以上的線上請求量。項目前后對比指標改造前改造后核心模塊單元測試覆蓋率個位數(shù)58%跨模塊隱性依賴數(shù)量23040 以下需求平均交付周期7 天3.5 天線上故障年度累計11 次4 次新同學上手業(yè)務代碼時間約 3 周約 1 周還有一個容易被忽視的數(shù)字刪除的僵尸代碼約兩萬行。代碼量減少但功能全部保留這對后續(xù)維護成本的降低立竿見影。5.2 流程制度的沉淀從靠人自覺到靠機制約束T3Code 最值錢的產(chǎn)出不是代碼本身而是三套機制第一套是依賴約束構建檢查。我們在構建流水線里加了一步自動化檢查任何模塊如果引用了其他模塊的內部實現(xiàn)類構建直接失敗。新代碼想跨模塊調用必須走對方提供的公開接口。這個約束一上線架構腐化的速度立刻被摁住了。第二套是灰度開關體系。所有模塊改造都通過配置中心控制放量比例運營和客服可以在不聯(lián)系研發(fā)的情況下緊急把某條鏈路切回老實現(xiàn)。這個能力在項目之后變成所有新功能的標配。第三套是代碼所有權制度。每個模塊指定一個負責人和一個后備負責人在代碼評審時有最終決策權。以前出了問題大家互相推現(xiàn)在每個模塊都有明確話事人線上告警第一時間就能定位到人。5.3 二期規(guī)劃T3Code 結束后我們打算做什么一期解決了代碼結構問題二期我們想推進兩件事一是可觀測性把鏈路追蹤和日志體系補完善目標是線上出問題能在五分鐘內定位到具體代碼行二是性能優(yōu)化針對熱點接口做緩存和讀寫分離改造。這兩件事放在一期的后面做是順理成章的結構理順了性能優(yōu)化的改動才敢動手鏈路追蹤建好了未來任何改造都有更細的排查抓手。不過二期具體排期還沒定得看業(yè)務側節(jié)奏優(yōu)先級上我會更偏向可觀測性性能優(yōu)化可以跟著業(yè)務痛點走。6. 最后說點自己人之間的大實話T3Code 整個項目從立項到收尾前后花了大約四個半月。比最初計劃的三個月超出了不少但整體節(jié)奏還在可控范圍內。復盤時大家最大的共識是技術型項目的排期一定要預留 buffer這個 buffer 不是給寫代碼留的是給踩坑留的。我們最后統(tǒng)計下來純開發(fā)時間只占總時長的 55% 左右剩下全在測試補樣本、排查隱式依賴、修數(shù)據(jù)同步這些看起來不起眼但繞不過去的事情上。如果你想在自己團隊發(fā)起類似的項目我給三條最樸素的建議第一先花充足時間做現(xiàn)狀盤點別急著寫代碼你把依賴關系畫清楚的那一刻改造方案其實已經(jīng)呼之欲出了第二從最容易被驗證的模塊下手頭兩個模塊成功上線帶來的團隊信心比任何激勵都管用第三一定把不改什么也寫進立項文檔它能幫你擋掉一半以上的需求干擾。T3Code 這個代號以后大概還會出現(xiàn)在我們的分支名里不過作為一個階段的標記它已經(jīng)完成了自己的使命。系統(tǒng)的代碼還在一天天演進但至少現(xiàn)在我們改訂單模塊時不用再心驚膽戰(zhàn)地翻那兩千個類了。