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