代碼倉(cāng)庫(kù)里那套老模塊已經(jīng)七歲高齡了。它用著十幾年前流行的分層架構(gòu)Service層里躺著三千行的上帝類方法命名從doProcess到processData2再到handleDataFinal像極了在代碼里玩俄羅斯套娃。每次加需求開發(fā)都得先在IDE里全局搜索調(diào)用鏈生怕漏掉某個(gè)藏在工具類里的隱式狀態(tài)。真正讓我下決心的不是潔癖發(fā)作而是一個(gè)生產(chǎn)事故——某個(gè)并發(fā)場(chǎng)景下由于共享的可變靜態(tài)Map沒有做同步控制導(dǎo)致線上訂單數(shù)據(jù)串了。那個(gè)周五晚上我盯著監(jiān)控面板上飆紅的錯(cuò)誤率忽然意識(shí)到修修補(bǔ)補(bǔ)已經(jīng)不能解決信任危機(jī)了這個(gè)模塊需要的是一次徹底的重生。重寫之前先回答三個(gè)“為什么”很多人把重寫當(dāng)成一場(chǎng)技術(shù)狂歡但從老系統(tǒng)繼承而來的業(yè)務(wù)邏輯里藏著無數(shù)個(gè)“當(dāng)初為什么這么寫”的暗坑。重寫最大的敵人不是舊代碼太爛而是我們對(duì)業(yè)務(wù)真相的一知半解。我做的第一件事不是新建Spring Boot項(xiàng)目而是把舊模塊的每個(gè)方法按調(diào)用頻次和異常日志導(dǎo)出成一份清單和產(chǎn)品經(jīng)理、測(cè)試同事一起過了一遍“哪些邏輯現(xiàn)在還在用、哪些已經(jīng)死了十年”。這個(gè)過程枯燥卻關(guān)鍵它讓我發(fā)現(xiàn)有四成的代碼——包括那些看起來“高大上”的策略模式實(shí)現(xiàn)——實(shí)際上從未被任何入口觸達(dá)過。它們是技術(shù)債的利息早已逾期卻依然躺在代碼里增加每個(gè)后來者的認(rèn)知負(fù)擔(dān)。我也問了團(tuán)隊(duì)里的老成員這個(gè)模塊為什么會(huì)有兩個(gè)含義幾乎相同的狀態(tài)字段答案是他也不清楚只記得當(dāng)初為了兼容某個(gè)銀行接口而臨時(shí)加的。這種“不知道為什么要存在”的代碼正是重寫時(shí)最危險(xiǎn)的陷阱。如果你不能解釋舊代碼中每一個(gè)分支和異常處理的意義那你就還沒有資格動(dòng)手重寫。我讓團(tuán)隊(duì)用一周時(shí)間把舊模塊的所有魔法數(shù)字、空指針保護(hù)、特殊字符過濾都標(biāo)注了來源有的來自監(jiān)管要求有的來自某個(gè)大客戶的定制需求還有的純粹是老板拍腦袋的結(jié)果。做完這步我才敢在白板上畫出新的領(lǐng)域模型。那段日子我們反復(fù)問自己這個(gè)模塊存在的本質(zhì)是什么是用狀態(tài)機(jī)管理訂單流轉(zhuǎn)還是用模板方法抽取公共流程是處理不同支付渠道的差異還是屏蔽底層通訊協(xié)議的變化最后我們達(dá)成共識(shí)——這個(gè)模塊的真正核心是“流程編排與狀態(tài)一致性”而不是某段具體的計(jì)算邏輯。明確了核心之后那些繁瑣的如果判斷就能被重新組織成更清晰的結(jié)構(gòu)。重寫不是拿新語(yǔ)言重抄一遍舊代碼而是借著重寫的機(jī)會(huì)重新審視問題域把埋在實(shí)現(xiàn)細(xì)節(jié)里的本質(zhì)抽象出來。第一次妥協(xié)我選擇了“不那么干凈”的落地方式理想很豐滿用EventSourcing解決狀態(tài)溯源用DCI架構(gòu)劃分角色行為用響應(yīng)式流處理高并發(fā)。但現(xiàn)實(shí)是團(tuán)隊(duì)里除了我沒人寫過Reactor生產(chǎn)環(huán)境的技術(shù)棧也不允許引入太多新的中間件。技術(shù)選型不是給你自己選是給半年后接手你代碼的人選。于是我在第一版設(shè)計(jì)里砍掉了事件溯源保留了關(guān)系型數(shù)據(jù)庫(kù)用樂觀鎖加版本號(hào)來控制并發(fā)。有人會(huì)嘲笑這不夠摩爾但我知道在這個(gè)業(yè)務(wù)場(chǎng)景下傳統(tǒng)的事務(wù)加鎖已經(jīng)足夠保證數(shù)據(jù)一致性而事件溯源帶來的回放復(fù)雜性對(duì)我們的審計(jì)需求是過度設(shè)計(jì)。另一個(gè)妥協(xié)發(fā)生在對(duì)象模型上。舊系統(tǒng)用的是貧血模型Service層包攬了所有業(yè)務(wù)邏輯實(shí)體類只有g(shù)etter/setter。我原本想徹底轉(zhuǎn)向充血模型把業(yè)務(wù)規(guī)則下沉到領(lǐng)域?qū)ο髢?nèi)部?？勺屑?xì)一分析發(fā)現(xiàn)這個(gè)模塊的業(yè)務(wù)規(guī)則和外部依賴耦合極重每條規(guī)則都要查配置表、調(diào)用遠(yuǎn)程服務(wù)甚至要讀取當(dāng)前登錄用戶的權(quán)限上下文。強(qiáng)行充血只會(huì)讓領(lǐng)域?qū)ο蟊成蠠o休止的基礎(chǔ)設(shè)施依賴到時(shí)既測(cè)不了單元也講不清邊界。我最后采用了折中方案核心狀態(tài)變更相關(guān)的規(guī)則內(nèi)聚到實(shí)體中而涉及外部協(xié)同的流程邏輯保留在應(yīng)用服務(wù)層。這不算漂亮但每個(gè)類都講得清楚自己的責(zé)任。代碼結(jié)構(gòu)上也做了取舍。我放棄了原先單模塊的Maven工程拆成三個(gè)子模塊domain純Java無Spring依賴、application用例編排、infrastructure數(shù)據(jù)庫(kù)和消息隊(duì)列實(shí)現(xiàn)。分層這件事知易行難。很多人分層只是換了個(gè)包名依賴方向照樣亂成一鍋粥。為了讓依賴規(guī)則名副其實(shí)我寫了個(gè)自定義的ArchUnit測(cè)試在CI里強(qiáng)制檢查domain層不能引用infrastructure的任何類application層只能依賴domain接口。剛開始成員還經(jīng)常編譯不過后來慢慢形成了肌肉記憶。這種強(qiáng)制約束比代碼評(píng)審里的口頭提醒有效得多。那些Java特性幫了大忙也坑了不少人重寫過程中我認(rèn)真用上了Java新語(yǔ)法。record類替換了那堆lombok注解switch表達(dá)式消除了好幾個(gè)“Fall-through”陷阱Stream的toList讓收集器不再啰嗦。Java最迷人的地方不是它能變出飛碟而是它在保守的版本演進(jìn)里逐步放下歷史包袱。用Map.of構(gòu)造不可變集合替換Collections.unmodifiableMap那段重構(gòu)至少消滅了三個(gè)潛在的NPE來源。團(tuán)隊(duì)在代碼規(guī)范里約定返回值一律不可變?nèi)雲(yún)⒓喜蛔龇烙钥截惖仨氃谧⑨尷飿?biāo)明所有權(quán)。這種顯式的約定比靠自覺健壯得多。真正讓我反思的是Optional。我用它包裝了所有可能為null的查詢結(jié)果看起來很美——直到有人對(duì)我說“你這個(gè)接口返回Optional但調(diào)用方根本不知道該怎樣優(yōu)雅處理它?！蔽一乜创a確實(shí)滿屏的.orElseThrow(() - new BizException(xxx不存在))本質(zhì)上和過去if(obj null) throw沒有區(qū)別只是多了一層盒子的儀式感。Optional的正確用法不是消滅null而是強(qiáng)迫你在類型系統(tǒng)層面表達(dá)“可能缺失”這一語(yǔ)義?？蒍ava的Optional本身也是對(duì)象忘了檢查照樣NPE。我在這次重寫里學(xué)會(huì)了只在“公有接口的返回值”和“集合內(nèi)元素提取”兩層使用它內(nèi)部方法的局部變量絕不濫用。另一個(gè)坑是CompletableFuture。我為了提升批量查詢性能把十幾個(gè)遠(yuǎn)程調(diào)用寫成異步并行然后用allOf().join()等待。上線一個(gè)禮拜后觀察到了間歇性的線程饑餓。排查下來是因?yàn)楣簿€程池被某個(gè)第三方SDK的阻塞IO給占光了。異步編程的最大騙局是你以為加了async就快了其實(shí)只是把等待挪了個(gè)地方順便把問題藏進(jìn)了線程池。后來我改用有界線程池加超時(shí)控制并且對(duì)聚合任務(wù)增加了數(shù)量限制超過二十個(gè)查詢就分批絕不無限并行。這個(gè)教訓(xùn)告訴我語(yǔ)言的特性永遠(yuǎn)是好用的但用不用、用多狠取決于你對(duì)運(yùn)行環(huán)境的敬畏。重構(gòu)中的“業(yè)務(wù)遷移”才是真正的硬骨頭代碼遷移容易數(shù)據(jù)遷移和業(yè)務(wù)補(bǔ)償才見功力。這個(gè)模塊維護(hù)著訂單的草稿、待審批、處理中、成功、失敗、已撤銷六種狀態(tài)。舊代碼在狀態(tài)變更時(shí)散落著if(order.getStatus()2)這樣的硬編碼甚至有兩處地方用字符串“success”和數(shù)字“3”混用。我在新模型里定義了枚舉OrderStatus并給每個(gè)狀態(tài)轉(zhuǎn)換寫了校驗(yàn)邏輯。但真正驚心動(dòng)魄的是存量數(shù)據(jù)舊的“處理中”狀態(tài)在歷史上曾經(jīng)表示過兩種不同的含義光靠狀態(tài)碼無法區(qū)分。我翻遍了歸檔的數(shù)據(jù)庫(kù)備份比對(duì)操作流水和日志最后不得不在新模型里增加一個(gè)sourceTraceId字段用來關(guān)聯(lián)那批“歷史遺留處理中”的訂單讓它們?cè)诤笈_(tái)任務(wù)里逐步補(bǔ)償終結(jié)。每一步數(shù)據(jù)遷移都像是在給飛行中的飛機(jī)換引擎你必須準(zhǔn)備好在萬米高空的迫降方案。我們采用雙寫策略新版代碼上線后先跑灰度流量同時(shí)旁路把關(guān)鍵操作同步到舊模塊的日志表里以便隨時(shí)回滾。為了對(duì)比新舊模塊的結(jié)果一致性我在旁路里記錄了request和response的摘要哈希每天跑一邊比對(duì)任務(wù)找出所有不一致的case。這個(gè)過程極其折磨人——大部分不一致是因?yàn)榕f代碼的bug被新代碼修正了比如原來漏判了某種優(yōu)惠組合現(xiàn)在正確計(jì)算了。還有小部分是新代碼自身的問題多數(shù)發(fā)生在邊界條件下的空值處理。我們花了兩周時(shí)間把對(duì)賬差異從每天幾百條縮小到個(gè)位數(shù)才敢逐步放量。回滾預(yù)案不是擺設(shè)。我們?cè)诎l(fā)布平臺(tái)準(zhǔn)備了三個(gè)開關(guān)功能開關(guān)、讀流量切回、寫流量切回。最成功的重寫是當(dāng)用戶毫無感知時(shí)換掉了底座最好的回滾是永遠(yuǎn)用不上的回滾。但人算不如天算?；叶鹊桨俜种囊粋€(gè)晚上我們收到告警某個(gè)渠道的回調(diào)處理耗時(shí)上漲了三倍。定位后發(fā)現(xiàn)新代碼里我用了一個(gè)分布式鎖來防止重復(fù)回調(diào)原本以為redis鎖的開銷可忽略但鎖的key設(shè)計(jì)不夠均勻?qū)е峦粋€(gè)訂單的多次回調(diào)全部擠到了同一把鎖上產(chǎn)生了串行等待。我快速調(diào)整了鎖的粒度變成“訂單號(hào)回調(diào)事件類型”的組合并加了localCache做首屏緩沖。凌晨一點(diǎn)半監(jiān)控曲線終于恢復(fù)平滑。那天晚上我對(duì)著窗外想為什么重寫一個(gè)模塊這么難因?yàn)榕f系統(tǒng)里每一個(gè)臃腫的設(shè)計(jì)都曾經(jīng)解決過某個(gè)未被文檔記錄的突發(fā)問題。讓測(cè)試替我說真話老代碼沒有單元測(cè)試集成測(cè)試也只是冒煙級(jí)別的“跑一遍不報(bào)錯(cuò)”。重寫給了我補(bǔ)齊測(cè)試的機(jī)會(huì)。但我不敢寫那種脆弱的、只校驗(yàn)內(nèi)部調(diào)用的單元測(cè)試。測(cè)試不是用來證明代碼能跑而是用來記錄設(shè)計(jì)決策讓后來的修改者看見“這里為什么不能輕易亂動(dòng)”。我鼓勵(lì)團(tuán)隊(duì)用真實(shí)業(yè)務(wù)用例驅(qū)動(dòng)開發(fā)每個(gè)需求先抽象出幾條Given-When-Then場(chǎng)景再寫實(shí)現(xiàn)。測(cè)試名就用完整的句子描述行為比如shouldApproveOrderWhenBalanceSufficientAndRiskPassed。這些測(cè)試后來成了新團(tuán)隊(duì)的活文檔——比什么Swagger和Word方案都直觀。覆蓋率是個(gè)容易騙人的指標(biāo)。我看到很多項(xiàng)目把覆蓋率刷到90%卻只測(cè)了happy path異常分支全是空的。我做了個(gè)簡(jiǎn)單的規(guī)則凡是在catch塊中吞掉異常的地方必須寫一個(gè)觸發(fā)該異常的測(cè)試凡是可能出現(xiàn)null的返回值必須寫一個(gè)“缺失時(shí)表現(xiàn)如何”的測(cè)試。這兩種測(cè)試通常沒人愛寫但它們是生產(chǎn)環(huán)境真正的護(hù)身符。重寫期間我們遇到過一個(gè)特別隱蔽的bug在新代碼里我把BigDecimal的除法默認(rèn)精度寫成2導(dǎo)致某個(gè)渠道的費(fèi)率計(jì)算在極端情況下?lián)p失了0.001元。單元測(cè)試當(dāng)時(shí)沒暴露因?yàn)闇y(cè)試數(shù)據(jù)都是整數(shù)倍。后來在屬性測(cè)試庫(kù)jqwik的輔助下生成了隨機(jī)的費(fèi)率組合才在回歸時(shí)捕到了這個(gè)誤差。所以一條失敗的分支測(cè)試價(jià)值勝過一百條成功的粗粒度測(cè)試。這也是我后來堅(jiān)持在做代碼評(píng)審時(shí)先看測(cè)試再看實(shí)現(xiàn)的原因。但測(cè)試也帶來了新的煩惱。重量級(jí)的SpringBootTest啟動(dòng)太快導(dǎo)致一次全量測(cè)試要跑十幾分鐘開發(fā)者只想跑單測(cè)卻被集成測(cè)試拖累。我重新劃分了測(cè)試金字塔純領(lǐng)域邏輯的測(cè)試用JUnit5AssertJ不加載Spring上下文涉及持久層的測(cè)試用Testcontainers起一個(gè)真實(shí)PostgreSQL真正的外部調(diào)用全部mock掉在應(yīng)用層只做契約測(cè)試。分層后單測(cè)速度回到秒級(jí)CI流水線里把集成測(cè)試和冒煙測(cè)試分開跑。工程能力的提升不是靠某一個(gè)炫技框架而是靠把每種測(cè)試放在合適的位置上運(yùn)轉(zhuǎn)。如今這個(gè)新模塊的測(cè)試全量跑完不到五分鐘而舊模塊根本沒有自動(dòng)化防線高下立見?？车舻摹皟?yōu)化”反而讓我明白什么是必需品重寫過程中我本打算趁手引入Redis緩存熱點(diǎn)訂單數(shù)據(jù)但在一番推演后決定不為當(dāng)下的性能瓶頸預(yù)支復(fù)雜性。這個(gè)模塊的寫操作本就占八成讀操作多發(fā)生在后臺(tái)的運(yùn)營(yíng)查詢場(chǎng)景而他們的查詢條件五花八門緩存命中率預(yù)料會(huì)很低。與其做一份徒增緩存和數(shù)據(jù)庫(kù)一致性維護(hù)負(fù)擔(dān)的緩存層不如用數(shù)據(jù)庫(kù)字段的索引優(yōu)化和查詢超時(shí)限制來硬扛。如果未來真的出現(xiàn)高并發(fā)讀需求那時(shí)候再引入CQRS也不遲而不必現(xiàn)在埋下雙寫不一致的地雷。這讓我反思「性能焦慮”——互聯(lián)網(wǎng)上到處是秒殺案例好像不加Redis就不好意思說自己是Java后端。但回歸到業(yè)務(wù)現(xiàn)實(shí)絕大多數(shù)模塊的壓力根本到不了需要微服務(wù)緩存消息隊(duì)列才能撐住的程度。每次想引入一個(gè)“先進(jìn)”組件前我都問自己一句沒了它系統(tǒng)會(huì)不會(huì)出問題會(huì)死嗎如果不會(huì)那就先不用。真正的業(yè)務(wù)瓶頸反而是數(shù)據(jù)一致性。我們?cè)诖a里用了Spring的Transactional管理數(shù)據(jù)庫(kù)事務(wù)但有些操作涉及調(diào)用外部接口如通知業(yè)務(wù)方、發(fā)送Mq消息“事務(wù)內(nèi)調(diào)用外部系統(tǒng)”是很多故障的溫床。舊模塊里就出現(xiàn)過本地事務(wù)回滾了但消息卻因?yàn)闆]在事務(wù)里而發(fā)出去了造成消費(fèi)者處理了不存在的訂單。我在新模型里改用事務(wù)發(fā)件箱模式把需要發(fā)出的消息先和業(yè)務(wù)狀態(tài)變更寫入同一張發(fā)件箱表事務(wù)提交后由后臺(tái)任務(wù)輪詢發(fā)送確認(rèn)成功后再標(biāo)記已發(fā)送。這個(gè)模式帶來了幾個(gè)額外的好處——消息可以重試、可以追蹤還能在緊急情況下人工干預(yù)。有時(shí)候看起來“繞遠(yuǎn)路”的架構(gòu)反而是最省心的近路。我希望每個(gè)重寫者都能明白重要的不是你能用多少新框架而是你能為業(yè)務(wù)守住哪些不可妥協(xié)的底線。來自代碼評(píng)審的爭(zhēng)吵與共識(shí)重寫不是一個(gè)人的戰(zhàn)斗。團(tuán)隊(duì)里我們每天花四十分鐘做代碼走查每次走查都圍繞“這段代碼是否講清了業(yè)務(wù)規(guī)則”展開。有一次新同事在application層里直接調(diào)用了orderRepository.save(order)之后緊跟著又調(diào)了一個(gè)orderDetailRepository.save(detail)。我說這里應(yīng)該由聚合根統(tǒng)一控制一致性他卻反駁說“事務(wù)本來就是原子的用戶訂單和明細(xì)表分兩次保存有什么問題”我讓他去領(lǐng)域模型圖上畫一下外賣訂單和訂單明細(xì)的關(guān)系他終于明白對(duì)業(yè)務(wù)而言訂單和明細(xì)必須作為一個(gè)整體變化如果允許在應(yīng)用層隨意分割操作以后就會(huì)出現(xiàn)“主表成功但明細(xì)失敗”的臟數(shù)據(jù)。代碼評(píng)審的價(jià)值不在于告訴別人“你寫得不對(duì)”而在于把隱藏在實(shí)現(xiàn)背后的思維模型拉到同一張桌面上。那次爭(zhēng)吵之后我們把聚合邊界畫在了團(tuán)隊(duì)內(nèi)的wiki上每個(gè)人改動(dòng)前先看邊界再動(dòng)手。我們也在評(píng)審中發(fā)現(xiàn)了過度設(shè)計(jì)的苗頭。一個(gè)同事試圖給狀態(tài)機(jī)引入狀態(tài)模式為每個(gè)狀態(tài)創(chuàng)建一個(gè)類。我問他這個(gè)模塊的狀態(tài)轉(zhuǎn)換路徑是固定的還是動(dòng)態(tài)的他說“未來可能加狀態(tài)?！蔽以賳枴澳隳芘e出一個(gè)真實(shí)的業(yè)務(wù)需求需要客戶端在運(yùn)行時(shí)動(dòng)態(tài)擴(kuò)展?fàn)顟B(tài)嗎”他沉默了。于是我們把狀態(tài)機(jī)收斂成一張枚舉轉(zhuǎn)換表簡(jiǎn)單粗暴但足夠用?！翱蓴U(kuò)展性”這話害了多少代碼它讓開發(fā)者忙著為想象中的未來搭建抽象腳手架卻對(duì)眼前真實(shí)的調(diào)用鏈無動(dòng)于衷。我的原則就是不存在的需求不需要留接口。代碼里的設(shè)計(jì)應(yīng)當(dāng)是寫代碼時(shí)真實(shí)思考的產(chǎn)物而不是對(duì)某個(gè)未知未來的謙卑預(yù)演。有時(shí)候業(yè)務(wù)方也會(huì)被拉進(jìn)評(píng)審。當(dāng)我們?yōu)槟硞€(gè)異常處理分支發(fā)生爭(zhēng)論時(shí)最直接的方法是問產(chǎn)品經(jīng)理“如果這個(gè)操作超過30秒還沒成功用戶最合理的體驗(yàn)是什么”產(chǎn)品說可以提示“處理中”后臺(tái)稍后通過異步任務(wù)補(bǔ)償。于是一場(chǎng)關(guān)于“要拋異常還是返回重試碼”的爭(zhēng)論戛然而止。技術(shù)決策最終的裁判是用戶的真實(shí)感受不是技術(shù)社區(qū)里的最佳實(shí)踐。我讓團(tuán)隊(duì)把這類從業(yè)務(wù)反饋引發(fā)技術(shù)決策的case記錄下來形成了一份“決策日志”。后來每個(gè)新人遇到類似問題先查決策日志比再討論一個(gè)下午高效得多。上線之后的反思重寫本質(zhì)上是一次風(fēng)險(xiǎn)投資新模塊上線運(yùn)行三個(gè)月后線上故障率下降了至少80%平均響應(yīng)時(shí)間縮短了四十個(gè)百分點(diǎn)。代碼行數(shù)從舊版本的八千行減少到五千行左右但這并不是最重要的收獲。真正讓我意識(shí)到重寫價(jià)值的是一次新需求的交付流程過去需要兩天時(shí)間梳理舊邏輯再小心翼翼地拼代碼如今只花了半天時(shí)間在狀態(tài)機(jī)新增一個(gè)節(jié)點(diǎn)并補(bǔ)充一條轉(zhuǎn)化規(guī)則就完成了。重寫不是炫技不是把代碼搬到更新的框架上以求心安而是為了讓每一次需求迭代都能踩在堅(jiān)實(shí)的、可理解的地基上。代價(jià)是重寫耗費(fèi)了約三個(gè)人月時(shí)間期間團(tuán)隊(duì)承受了與業(yè)務(wù)方解釋“為什么一個(gè)看起來沒變的模塊這么久”的壓力。若從純粹的財(cái)務(wù)角度看這筆投入也許需要一年多的維護(hù)成本節(jié)省才能回本。有人問我以后遇到一個(gè)爛模塊還會(huì)選擇重寫嗎我的回答是會(huì)但不會(huì)輕易動(dòng)手。重寫前必須回答“業(yè)務(wù)規(guī)則是否完全已知”和“失敗后是否有退路”這兩道題。如果業(yè)務(wù)邏輯已經(jīng)像一鍋燒糊的粥且沒有任何文檔、測(cè)試或?qū)＜矣洃浛梢猿吻迕恳涣Ｃ诪槭裁丛阱伒啄侵貙懙娘L(fēng)險(xiǎn)和直接寫一個(gè)全新的功能不相上下。而如果團(tuán)隊(duì)沒有足夠的時(shí)間窗口和可以隨時(shí)回滾的灰度機(jī)制重寫就是一次豪賭。如果讓我再走一遍這段歷程我會(huì)更早地引入契約測(cè)試和數(shù)據(jù)對(duì)賬機(jī)制而不是等到功能開發(fā)完才開始補(bǔ)。我也會(huì)更克制地使用Java的并發(fā)工具——新版本里我們用虛擬線程替換了大部分異步鏈?zhǔn)秸{(diào)用讓代碼讀起來又回到了同步的樣子卻依然能享受高并發(fā)下的吞吐彈性。有時(shí)候最好的寫法是讓讀代碼的人根本不需要猜測(cè)線程模型。用Java重寫一個(gè)業(yè)務(wù)模塊表面上是換了語(yǔ)言的新寫法其實(shí)換的是我們與舊世界之間的認(rèn)知契約。每一處優(yōu)雅設(shè)計(jì)背后都有一灘泥巴被清理每一個(gè)取舍背后都是一次對(duì)業(yè)務(wù)深挖的證明。我把這些反思寫下來既是為了告慰那無數(shù)個(gè)調(diào)試到深夜的日子也是想告訴后來者重寫代碼并不是浪漫的技術(shù)冒險(xiǎn)而是一場(chǎng)需要謙卑、紀(jì)律和勇氣的徒步遠(yuǎn)征。走完全程你會(huì)發(fā)現(xiàn)自己帶的不是代碼而是一份明明白白的責(zé)任。