代碼結(jié)構(gòu)這件事我最近感觸特別深。團(tuán)隊(duì)里來了個(gè)新人接手一個(gè)跑了兩年多的老項(xiàng)目看代碼的時(shí)候眉頭皺得能夾死蚊子。不是說他水平不行而是項(xiàng)目里到處都是“看起來能跑但根本不敢動(dòng)”的代碼——一個(gè)函數(shù)五六百行模塊之間你依賴我我依賴你想加個(gè)新功能得先花三天理解舊邏輯。后來我們一起花了兩個(gè)周末做了一輪結(jié)構(gòu)性調(diào)整從那之后我才真正意識到Programming Concepts CodeStructure 這種聽起來偏理論的話題實(shí)際上是所有實(shí)際開發(fā)工作的地基。這篇“第3篇”我想專門聊聊代碼組織與模塊化設(shè)計(jì)——不聊語法、不聊算法就聊怎么把一堆散亂的代碼整理成一套穩(wěn)定、可維護(hù)、能持續(xù)演進(jìn)的結(jié)構(gòu)。這個(gè)內(nèi)容適合誰三類人第一類寫了一陣子代碼但總覺得項(xiàng)目越來越亂的人你需要這套思路來理清方向第二類剛開始帶項(xiàng)目或帶新人的開發(fā)者你需要在結(jié)構(gòu)層面建立標(biāo)準(zhǔn)第三類純粹對代碼質(zhì)量有追求、想寫出更體面代碼的工程師。不管你是后端、前端還是全棧底層的組織邏輯是相通的。1. 模塊化設(shè)計(jì)的底層邏輯1.1 為什么模塊化是代碼結(jié)構(gòu)的核心模塊化這個(gè)詞被說爛了但真正理解它的人不多。我見過很多項(xiàng)目名義上分了包、分了目錄、分了組件實(shí)際上只是一堆文件的物理堆疊。真正的模塊化不是“把代碼放到不同的文件夾里”而是“讓代碼之間存在清晰的、可管理的邊界”。這個(gè)道理像整理房間。你把衣服扔進(jìn)衣柜、書放到書架上、雜物塞進(jìn)抽屜這叫分類不叫整理。整理的意思是每樣?xùn)|西有固定的歸屬位置拿取和歸位都不需要思考且互不干擾。模塊化就是給代碼建立這種“固定歸屬感”——這個(gè)模塊只負(fù)責(zé)做這一類事它內(nèi)部的細(xì)節(jié)不向外暴露外部只通過約定好的方式跟它協(xié)作。從工程角度說模塊化帶來三個(gè)核心收益可讀性、可測試性、可演進(jìn)性?？勺x性很好理解——看到userService.getUserById(id)就知道它干什么而不是打開一個(gè)五百行的函數(shù)去猜?？蓽y試性意味著你可以單獨(dú)驗(yàn)證某個(gè)模塊的行為而不需要把整個(gè)系統(tǒng)跑起來。可演進(jìn)性最值錢當(dāng)業(yè)務(wù)變化時(shí)你能準(zhǔn)確判斷該改哪里、不該改哪里從而把影響范圍控制在最小。很多項(xiàng)目為什么越到后期越難維護(hù)我觀察下來九成是因?yàn)樵缙跊]有建立模塊邊界意識。寫第一版功能時(shí)覺得“就這點(diǎn)事直接寫就好了”于是業(yè)務(wù)邏輯和頁面渲染混在一起數(shù)據(jù)處理和接口調(diào)用耦合在一起。等第二版、第三版功能疊加進(jìn)來這些當(dāng)初的“順手”就變成了債——每次改動(dòng)都牽一發(fā)動(dòng)全身測試范圍越擴(kuò)越大發(fā)布風(fēng)險(xiǎn)越來越高。1.2 模塊拆分的三條鐵律拆模塊不是拍腦袋我總結(jié)出三條原則基本可以覆蓋絕大多數(shù)場景。第一條單一職責(zé)。一個(gè)模塊只對一類變化負(fù)責(zé)。這個(gè)說法聽起來抽象落地的時(shí)候有一個(gè)很實(shí)用的判別方法描述這個(gè)模塊的職責(zé)時(shí)如果句子中出現(xiàn)“和”“以及”“還有”這類連接詞八成是職責(zé)不單一。比如“用戶數(shù)據(jù)管理模塊”是好的描述“用戶數(shù)據(jù)管理和通知發(fā)送模塊”就有問題——通知發(fā)送和用戶數(shù)據(jù)是兩類變化放在一起只會互相牽扯。第二條單向依賴。模塊之間可以有依賴關(guān)系但必須是單向的不能循環(huán)。A 依賴 B、B 依賴 C沒問題但如果 A 又依賴 C、C 又依賴 A那就是環(huán)早晚出問題。環(huán)存在的直接后果是沒法單獨(dú)修改其中任何一個(gè)模塊因?yàn)楦牧艘粋€(gè)另一個(gè)的結(jié)構(gòu)也要跟著動(dòng)。更麻煩的是循環(huán)依賴通常不是一次形成的而是隨著版本演進(jìn)逐漸滋生出來的——從一開始的小環(huán)到后面的大網(wǎng)等你注意到的時(shí)候已經(jīng)很難拆了。第三條封裝變化。模塊內(nèi)部怎么實(shí)現(xiàn)是它自己的事對外只暴露穩(wěn)定接口。我見過很多團(tuán)隊(duì)在“接口穩(wěn)定性”上吃虧一個(gè)模塊原來返回一個(gè) List后來需求變了要改成帶分頁信息的結(jié)果于是直接把返回值改成自定義對象結(jié)果所有調(diào)用方全部報(bào)錯(cuò)被迫一次性改了十幾個(gè)文件。如果當(dāng)初設(shè)計(jì)查詢接口時(shí)就考慮到“查詢結(jié)果可能包含元數(shù)據(jù)”這個(gè)變化點(diǎn)把返回結(jié)構(gòu)設(shè)計(jì)成包含數(shù)據(jù)和輔助信息的形式后面就不會這么被動(dòng)。這三條鐵律背后其實(shí)是一個(gè)共同的主旨讓模塊之間的關(guān)系盡量簡單、穩(wěn)定讓模塊內(nèi)部的變化盡量封閉、可控。關(guān)系簡單了系統(tǒng)就容易被理解內(nèi)部變化可控了系統(tǒng)就經(jīng)得起迭代。2. 實(shí)戰(zhàn)中最常用的三種代碼組織模式2.1 按業(yè)務(wù)切片收口變化模式一按業(yè)務(wù)切片組織。這種組織方式的核心思想是業(yè)務(wù)邊界就是模塊邊界一個(gè)業(yè)務(wù)用例走完它的完整鏈路相應(yīng)的代碼都收攏在自己的地盤里。我們做某個(gè)模擬項(xiàng)目X時(shí)一開始按“controller、service、dao”這種技術(shù)層次分包。新功能上線要把用戶注冊流程里增加一個(gè)校驗(yàn)步驟得同時(shí)改 controller 里的接口、service 里的業(yè)務(wù)邏輯、dao 里的數(shù)據(jù)訪問三層文件分散在三個(gè)目錄橫跨整個(gè)項(xiàng)目。后來重構(gòu)改成按業(yè)務(wù)切片所有跟“用戶注冊”相關(guān)的代碼——接口定義、業(yè)務(wù)處理、數(shù)據(jù)存儲——都放在同一個(gè)包里。改注冊流程只需要進(jìn)這一個(gè)包牽涉面天然小很多。按業(yè)務(wù)切片有個(gè)顯著的額外好處它對需求變更有天然的收口能力。業(yè)務(wù)場景是相對穩(wěn)定的概念技術(shù)實(shí)現(xiàn)是相對易變的細(xì)節(jié)。按業(yè)務(wù)切分等于把易變的細(xì)節(jié)關(guān)在每個(gè)業(yè)務(wù)模塊內(nèi)部跨模塊的影響面自然就小了。不過這個(gè)模式對初創(chuàng)項(xiàng)目或業(yè)務(wù)未成型的項(xiàng)目不太友好因?yàn)闃I(yè)務(wù)邊界本身還在頻繁調(diào)整切太細(xì)反而增加重構(gòu)成本。什么時(shí)候適合切我的經(jīng)驗(yàn)是核心業(yè)務(wù)鏈路已經(jīng)跑通、后續(xù)大概率會持續(xù)迭代時(shí)盡早切比晚切好。2.2 按技術(shù)層切分穩(wěn)定邊界模式二按技術(shù)層切分就是經(jīng)典的“表現(xiàn)層、業(yè)務(wù)層、數(shù)據(jù)層”。這個(gè)模式的邏輯跟業(yè)務(wù)切片正好相反它把系統(tǒng)的“技術(shù)關(guān)注點(diǎn)”作為劃分依據(jù)讓所有跟特定技術(shù)相關(guān)的代碼集中在一起形成清晰的分層依賴關(guān)系。這種模式的優(yōu)勢是邊界極穩(wěn)定。無論業(yè)務(wù)怎么變技術(shù)層之間單向依賴的關(guān)系是很難被破壞的——表現(xiàn)層依賴業(yè)務(wù)層、業(yè)務(wù)層依賴數(shù)據(jù)層這個(gè)方向幾乎是所有開發(fā)者默認(rèn)遵守的規(guī)則團(tuán)隊(duì)心智成本很低。新人進(jìn)來上手也快看層就知道代碼該寫在哪。但代價(jià)也很明確一旦業(yè)務(wù)邏輯跨越多個(gè)層就會產(chǎn)生“垂直切片”的零散分布。比如一個(gè)簡單的“修改用戶資料”操作你要在表現(xiàn)層寫一個(gè)方法、在業(yè)務(wù)層寫一個(gè)方法、在數(shù)據(jù)層寫一個(gè)方法單個(gè)操作在代碼層面是斷裂的。當(dāng)系統(tǒng)的業(yè)務(wù)復(fù)雜度超過技術(shù)復(fù)雜度時(shí)這種模式會讓每次改動(dòng)都牽扯多個(gè)層團(tuán)隊(duì)不得不頻繁做跨層聯(lián)調(diào)。這兩種模式不是二選一的對立關(guān)系而是互補(bǔ)關(guān)系。我現(xiàn)在的做法是總體框架按業(yè)務(wù)切片組織每個(gè)業(yè)務(wù)模塊內(nèi)部再按技術(shù)職責(zé)做細(xì)分。這樣既能享受業(yè)務(wù)收口的好處又不會讓模塊內(nèi)部的代碼亂成一鍋粥。2.3 混合組織業(yè)務(wù)優(yōu)先、技術(shù)兜底說到“業(yè)務(wù)優(yōu)先、技術(shù)兜底”這基本是我目前最推薦的做法。具體來說拆包時(shí)先看業(yè)務(wù)——這個(gè)代碼是為哪個(gè)業(yè)務(wù)場景服務(wù)的歸到對應(yīng)業(yè)務(wù)包下如果一段代碼被多個(gè)業(yè)務(wù)模塊共享再把它下沉到技術(shù)層或公共層?；旌辖M織的核心在于“判定歸屬”的順序。很多團(tuán)隊(duì)糾結(jié)“這段代碼放業(yè)務(wù)包還是放技術(shù)包”其實(shí)只要問一句話就可以了這段代碼是“某一類業(yè)務(wù)特有的邏輯”還是“多種業(yè)務(wù)都能復(fù)用的通用邏輯”前者進(jìn)業(yè)務(wù)模塊后者進(jìn)公共層。舉個(gè)例子一個(gè)“導(dǎo)出Excel報(bào)表”的功能。如果只有訂單模塊用那它就是訂單業(yè)務(wù)的一部分放訂單包里如果后續(xù)用戶模塊、庫存模塊都要導(dǎo)出報(bào)表你就應(yīng)該把它抽到公共的“導(dǎo)出工具”層讓各業(yè)務(wù)模塊調(diào)用。同一個(gè)功能在不同團(tuán)隊(duì)里的歸屬可能完全不同關(guān)鍵在“復(fù)用范圍”上。混合組織還需要注意“公共層”的管理口徑。很多人抽公共代碼后公共層逐漸膨脹成一個(gè)“垃圾場”各種沾邊不沾邊的工具都扔進(jìn)去。我的經(jīng)驗(yàn)是給公共層設(shè)一道“準(zhǔn)入標(biāo)準(zhǔn)”至少被兩個(gè)業(yè)務(wù)模塊復(fù)用且功能邊界明確。只被一個(gè)模塊用的代碼哪怕寫得很抽象也應(yīng)該先留在那個(gè)模塊內(nèi)部等第二次被復(fù)用再做抽離。這能有效避免過早抽象帶來的復(fù)雜度。3. 函數(shù)拆分與接口設(shè)計(jì)的實(shí)操要點(diǎn)3.1 函數(shù)拆分的判斷尺度模塊是容器函數(shù)才是真正干活的最小單位。函數(shù)的質(zhì)量直接決定代碼結(jié)構(gòu)的基礎(chǔ)質(zhì)量。很多項(xiàng)目模塊分得很合理但單個(gè)函數(shù)內(nèi)部又臭又長照樣讓人看不下去。關(guān)于函數(shù)拆分我見過很多不合理的做法要么極端到“一行一個(gè)函數(shù)”要么另一個(gè)極端“幾百行一把梭”。這兩個(gè)方向都不對。判斷一個(gè)函數(shù)該不該繼續(xù)拆我一般看三個(gè)信號。第一個(gè)信號是嵌套深度。一個(gè)函數(shù)里 if 嵌套超過三層或循環(huán)里套循環(huán)再套條件基本就該拆了。嵌套越深閱讀時(shí)大腦需要維持的“上下文棧”就越深出錯(cuò)的概率也越高。拆法很簡單把內(nèi)層嵌套體提取成一個(gè)獨(dú)立函數(shù)上層只保留“條件判斷調(diào)用”。第二個(gè)信號是存在“段落感”。當(dāng)你給函數(shù)寫注釋時(shí)發(fā)現(xiàn)注釋有兩三處以上而且每處注釋都描述一個(gè)不同的處理階段——比如“先校驗(yàn)參數(shù)”“再查詢數(shù)據(jù)”“最后組裝返回”這就說明這個(gè)函數(shù)做了三件不同的事應(yīng)該拆成三個(gè)獨(dú)立的函數(shù)。第三個(gè)信號是局部變量的數(shù)量。函數(shù)內(nèi)同時(shí)存在的變量超過四五個(gè)通常意味著它承擔(dān)了太多職責(zé)。變量多是“狀態(tài)復(fù)雜”的外在表現(xiàn)狀態(tài)一復(fù)雜后續(xù)邏輯分支就多函數(shù)就膨脹。拆函數(shù)有一個(gè)反直覺的要點(diǎn)不要為了“復(fù)用”而拆要為了“可讀性”而拆。復(fù)用是錦上添花可讀性是基本盤。一個(gè)函數(shù)只被調(diào)用一次但如果拆出來能讓主流程清晰可讀照樣值得拆。3.2 接口設(shè)計(jì)的三看原則接口是模塊之間的“門”門的寬窄、位置、朝向直接決定進(jìn)出是否順暢。我把接口設(shè)計(jì)總結(jié)成“三看原則”。一看參數(shù)。參數(shù)列表越短越好理想情況不超過三個(gè)。超過三個(gè)就要考慮是不是該封裝成一個(gè)對象了。這不僅是風(fēng)格問題——參數(shù)一多調(diào)用方的記憶負(fù)擔(dān)直線上升而且每個(gè)調(diào)用點(diǎn)都可能傳錯(cuò)順序。用對象傳參命名比位置好記也更容易擴(kuò)展而不破壞調(diào)用方。二看返回值。返回值要明確表達(dá)“成功了沒有、成功的結(jié)果是什么、失敗了為什么”。我看過很多代碼用返回 null 表示失敗這看似省事實(shí)則把錯(cuò)誤處理壓力轉(zhuǎn)嫁到了所有調(diào)用方身上。每一個(gè)調(diào)用方都得記得“返回值可能為 null”一旦漏判運(yùn)行時(shí)就可能拋出空指針。與其這樣不如在接口層面就把失敗路徑顯式化。比如返回結(jié)果對象包含成功標(biāo)志和失敗原因或者直接拋異常讓調(diào)用方在異常處理里做統(tǒng)一應(yīng)對。三看調(diào)用的“語義一致性”。接口名字要以“動(dòng)詞開頭”準(zhǔn)確描述“做了什么”而不是“是什么”。isValid(...)、calculateTotal(...)、loadUserProfile(...)都很清楚DataHandler(...)、UserManager(...)這類名字其實(shí)什么都沒說。接口是對行為的抽象不是對名詞的分類。取名字多花三十秒后面能省三個(gè)小時(shí)看代碼的時(shí)間。3.3 參數(shù)與返回值的約定參數(shù)和返回值的約定屬于那種“不寫進(jìn)規(guī)范文檔但每個(gè)成熟團(tuán)隊(duì)都會遵守”的隱性知識。這里我分享幾條自己實(shí)踐驗(yàn)過的約定。參數(shù)傳遞盡量選“穩(wěn)定的領(lǐng)域?qū)ο蟆鄙賯鳌奥銛?shù)據(jù)”。裸數(shù)據(jù)指基本類型、字符串、數(shù)字這種單點(diǎn)值領(lǐng)域?qū)ο笾赶瘛癠ser”“Order”這樣的業(yè)務(wù)實(shí)體。裸數(shù)據(jù)傳參的問題是缺乏語義上下文接收方要到讀取變量的位置才能拼湊出調(diào)用的意圖。領(lǐng)域?qū)ο髠鲄⒔邮辗揭谎劬椭雷约涸谔幚硎裁?。?dāng)然這也有例外——如果只用到某個(gè)對象里的一兩個(gè)字段傳整個(gè)對象反而暴露了過多信息這時(shí)候傳字段更合適。原則是看接收方實(shí)際需要多少信息夠用、剛好就行。返回值要保持“最小必要信息”。很多函數(shù)喜歡順手多返回幾個(gè)字段美其名曰“順便帶出來”這會造成調(diào)用方對函數(shù)職責(zé)的理解出現(xiàn)偏差。比如一個(gè)getUserName()的接口返回值里還帶了用戶等級調(diào)用方不禁會想“這個(gè)函數(shù)是不是還做了權(quán)限相關(guān)的事” 職責(zé)清晰的函數(shù)返回值里的每一個(gè)字段都應(yīng)該是調(diào)用方真正需要的。還有一個(gè)細(xì)節(jié)是“一致性”。同一個(gè)項(xiàng)目中類似的接口風(fēng)格要統(tǒng)一。要么都返回自定義結(jié)果對象要么都返回原始數(shù)據(jù)要么都拋異常千萬別一種情況返回對象、另一種情況拋異常、還有一種情況返回 null 然后靠調(diào)用方自己猜。約定統(tǒng)一帶來的最大好處是團(tuán)隊(duì)每個(gè)人調(diào)用接口時(shí)不需要“查文檔再判斷”看風(fēng)格就知道該怎么處理。4. 依賴管理讓代碼可燃可拆4.1 依賴方向控制的實(shí)操方法依賴管理是代碼結(jié)構(gòu)從“能跑”到“可維護(hù)”的分水嶺。一個(gè)系統(tǒng)的健康度很多時(shí)候不看它有多少行代碼而是看它的依賴關(guān)系是否清晰可控。實(shí)際開發(fā)中依賴失控最常見的形式就是“跨層破壞”。比如頁面層直接去調(diào)數(shù)據(jù)層的方法跳過了業(yè)務(wù)層。一次兩次無所謂次數(shù)多了層次結(jié)構(gòu)形同虛設(shè)。我見過最夸張的情況是一個(gè)展示按鈕的狀態(tài)頁面層直接查了三張表——業(yè)務(wù)校驗(yàn)全部繞過后續(xù)想加權(quán)限控制壓根找不到合適的切入點(diǎn)?？刂埔蕾嚪较蛴幸粋€(gè)非常實(shí)用的實(shí)操方法給每個(gè)模塊列一張“依賴清單”寫明它允許依賴誰、不允許依賴誰。這張清單不一定要寫進(jìn)正式文檔但要在代碼 Review 時(shí)作為檢查項(xiàng)。代碼審查的時(shí)候我必看的一環(huán)就是 import 語句——如果發(fā)現(xiàn)一個(gè)業(yè)務(wù)模塊直接 import 了其他業(yè)務(wù)模塊的內(nèi)部實(shí)現(xiàn)類就會要求給出解釋。若沒有合理理由一律打回。這個(gè)方法的成本極低收益卻很直接。它相當(dāng)于給項(xiàng)目立了一塊“交通指示牌”大家都在主干道上走偶爾有人想抄近道也會被攔下來。時(shí)間一長新的開發(fā)人員自然就養(yǎng)成了按指定方向組織代碼的習(xí)慣。還有一點(diǎn)值得注意依賴關(guān)系要可視化。你總覺得自己對項(xiàng)目的依賴結(jié)構(gòu)很了解但當(dāng)一個(gè)項(xiàng)目超過幾十個(gè)模塊后大腦很難裝下完整的依賴圖。我建議團(tuán)隊(duì)定期生成依賴圖看一眼哪里密度過高、哪里有環(huán)、哪里邊界模糊一目了然。持續(xù)觀察調(diào)整依賴結(jié)構(gòu)才不至于在不知不覺中腐化。4.2 抽象與實(shí)現(xiàn)分離的落地方式抽象與實(shí)現(xiàn)分離這個(gè)話在理論里講了很多遍但落到實(shí)際代碼里怎么操作很多人是迷糊的。我理解的核心就一句話別讓實(shí)現(xiàn)類之間直接互相依賴讓它們依賴抽象的接口。落地方式有很多最輕量的一種是“接口下沉”。當(dāng)兩個(gè)類都需要依賴同一個(gè)邏輯時(shí)把共同的依賴提取成接口讓雙方都面向接口編程。比如訂單模塊和庫存模塊都要訪問一個(gè)“庫存計(jì)數(shù)器”與其讓兩個(gè)模塊直接依賴同一個(gè)實(shí)現(xiàn)類不如抽一個(gè)InventoryCounter接口讓各模塊面向這個(gè)接口編程——后續(xù)如果計(jì)數(shù)器實(shí)現(xiàn)方式變了比如從數(shù)據(jù)庫改成內(nèi)存緩存只需要換實(shí)現(xiàn)不需要?jiǎng)诱{(diào)用方。另一種方式是依賴注入。不要在類的內(nèi)部直接 new 依賴對象而是通過構(gòu)造函數(shù)傳入。這帶來的直接好處是測試時(shí)可以傳入 mock 實(shí)現(xiàn)擴(kuò)展時(shí)可以替換新實(shí)現(xiàn)結(jié)構(gòu)調(diào)整時(shí)只需要改組裝點(diǎn)不需要?jiǎng)觾?nèi)部邏輯。它把“誰跟誰發(fā)生關(guān)系”這件事從每個(gè)類內(nèi)部提升到一個(gè)統(tǒng)一的組裝層面整個(gè)系統(tǒng)的耦合度因此大幅下降。不過抽象也不是越多越好。抽象的本質(zhì)是“用多一層間接換取易變點(diǎn)隔離”如果接口只有一個(gè)實(shí)現(xiàn)且短期內(nèi)看不到第二個(gè)實(shí)現(xiàn)那它就是在白交“復(fù)雜度稅”。我見過不少項(xiàng)目接口一大堆每個(gè)接口對應(yīng)一個(gè)實(shí)現(xiàn)類但這種抽象并沒有換來任何靈活性——因?yàn)闃I(yè)務(wù)根本沒到需要切換實(shí)現(xiàn)的時(shí)候。抽象的正確時(shí)機(jī)是你看到了“變化”的事實(shí)或者“變化”的強(qiáng)烈預(yù)兆而不是為了顯得“專業(yè)”。5. 代碼結(jié)構(gòu)演進(jìn)與重構(gòu)實(shí)錄5.1 一次真實(shí)的模塊重構(gòu)過程前面講了不少理論這里分享一個(gè)真實(shí)的重構(gòu)過程能看到這些原則是如何落地的。當(dāng)時(shí)手上的模擬項(xiàng)目X是一個(gè)中小型后臺管理系統(tǒng)一開始只有三四個(gè)核心模塊團(tuán)隊(duì)小、節(jié)奏快大家默契心照不宣模塊邊界基本靠個(gè)人感覺。結(jié)果半年后模塊數(shù)翻了一倍多問題集中爆發(fā)改動(dòng)一個(gè)功能光是在編譯依賴?yán)镎页鏊惺苡绊懙奈募秃臅r(shí)費(fèi)力每次上線前老員工都要對著一長串變更清單戰(zhàn)戰(zhàn)兢兢地評估風(fēng)險(xiǎn)。我們做了一個(gè)決定停下來做一次模塊化梳理。整個(gè)過程分四步。第一步盤點(diǎn)全貌。把項(xiàng)目里所有模塊列出來標(biāo)注每個(gè)模塊的職責(zé)描述、對外接口、內(nèi)部主要類、依賴了誰、被誰依賴。這一步花了兩個(gè)晚上產(chǎn)出是一張依賴關(guān)系圖。圖出來后問題一目了然有兩個(gè)模塊形成了雙向依賴有一個(gè)“工具”模塊實(shí)際肩負(fù)了業(yè)務(wù)邏輯但名字叫工具還有一個(gè)模塊依賴了六個(gè)模塊但被十個(gè)模塊依賴。第二步劃定目標(biāo)結(jié)構(gòu)。按照“業(yè)務(wù)優(yōu)先、技術(shù)兜底”的原則重新定義模塊劃分。原有模塊拆的拆、合的合、搬的搬目標(biāo)是每個(gè)模塊只跟少數(shù)幾個(gè)模塊發(fā)生依賴關(guān)系且方向明確。第三步逐步遷移。不要一次性大改風(fēng)險(xiǎn)太大。我們按模塊切分批次每個(gè)批次做“提取接口、移動(dòng)代碼、調(diào)整調(diào)用方、跑測試、上線”這一套動(dòng)作。每批遷移控制在兩天內(nèi)完成避免分支長期和大部隊(duì)脫節(jié)。第四步清理收尾。遷移完成后刪除所有不再使用的舊文件清理重復(fù)的公共代碼然后重新生成依賴圖跟目標(biāo)結(jié)構(gòu)做對照確認(rèn)。整個(gè)過程我們花了大概兩周。最顯著的變化是兩周后新加一個(gè)功能涉及面從橫跨七八個(gè)文件縮減到兩三個(gè)文件Review 的時(shí)長遠(yuǎn)低于過去因?yàn)楦膭?dòng)范圍肉眼可見地變小了。這一步的收益可以說是立竿見影。5.2 重構(gòu)中的安全網(wǎng)講完過程專門聊聊重構(gòu)的安全網(wǎng)問題。沒有安全網(wǎng)的重構(gòu)不是重構(gòu)是賭博。安全網(wǎng)的第一層是好的版本控制習(xí)慣。每個(gè)批次的重構(gòu)要獨(dú)立提交commit 信息寫清楚“移動(dòng)了什么、為什么移動(dòng)”。這樣萬一重構(gòu)出問題還能定位到具體改動(dòng)更重要的是獨(dú)立提交使每個(gè)批次能單獨(dú)被審查和回滾。我見過有些人一個(gè)重構(gòu)拉了個(gè)大分支兩周后才合回來期間主分支早就變了樣合并沖突解決到懷疑人生。安全網(wǎng)的第二層是測試。這里我要說一個(gè)比較硬的觀點(diǎn)在沒有基礎(chǔ)測試的項(xiàng)目里貿(mào)然做大規(guī)模重構(gòu)是不負(fù)責(zé)任的行為。不是說一定不能做而是要做的話必須先把核心路徑的測試補(bǔ)上。核心路徑怎么定義以當(dāng)天線上最頻繁被使用的功能為準(zhǔn)。把這些功能的輸入、輸出、異常分支覆蓋到重構(gòu)時(shí)才有一個(gè)可以依賴的“行為基準(zhǔn)線”。安全網(wǎng)的第三層是自動(dòng)化檢查。重構(gòu)期間我強(qiáng)烈建議至少加一個(gè)依賴方向的檢查工具。很多靜態(tài)檢查工具都支持自定義規(guī)則你可以加一條“模塊 A 不允許依賴模塊 B”的規(guī)則誰違反了直接標(biāo)紅。這比人工 Code Review 可靠得多——人總會累工具不會。還有一個(gè)我認(rèn)為最容易被低估的安全網(wǎng)小步提交加上頻繁回歸。每完成一個(gè)模塊的遷移就編譯一次、跑一遍核心測試、手動(dòng)點(diǎn)一遍關(guān)鍵流程。千萬別攢到最后一次回歸到那會兒問題疊加在一起根本沒頭緒排查。6. 常見問題與排查技巧實(shí)錄6.1 典型問題清單跟代碼結(jié)構(gòu)打交道久了常遇到的問題來來去去就那幾類整理了一個(gè)速查表供參考。問題現(xiàn)象根因分析處理建議改一個(gè)小功能要?jiǎng)雍芏辔募K邊界按技術(shù)層劃分或職責(zé)混雜沒有按業(yè)務(wù)收口依據(jù)業(yè)務(wù)場景重新規(guī)劃模塊邊界逐步遷移新增代碼不知道該放哪個(gè)包缺少清晰的模塊職責(zé)描述團(tuán)隊(duì)沒有統(tǒng)一的歸屬判斷標(biāo)準(zhǔn)建立模塊索引文檔標(biāo)注職責(zé)統(tǒng)一歸屬判斷標(biāo)準(zhǔn)循環(huán)依賴反復(fù)出現(xiàn)缺少依賴方向檢查工具Review 時(shí)沒把 import 關(guān)系當(dāng)重點(diǎn)引入檢查工具 Review 時(shí)檢查依賴立規(guī)則模塊越來越多公共層越來越亂公共層沒有準(zhǔn)入標(biāo)準(zhǔn)什么代碼都往里塞制定公共層準(zhǔn)入規(guī)則只放跨模塊復(fù)用的通用邏輯接口參數(shù)多且亂缺少參數(shù)對象意識封裝不足超出三四個(gè)參數(shù)就封裝成傳參對象模塊的測試特別難寫依賴具體實(shí)現(xiàn)而非接口、依賴注入缺失面向接口編程構(gòu)造函數(shù)注入依賴替換依賴以注入為例這個(gè)表格算是一個(gè)“自查清單”遇到代碼看不下去的時(shí)候打開對照一下基本能定位到病灶在哪個(gè)環(huán)節(jié)。6.2 排查思路與調(diào)試經(jīng)驗(yàn)如果代碼結(jié)構(gòu)已經(jīng)亂了從哪里著手看我有一套固定的排查思路按優(yōu)先級排。第一優(yōu)先是看“入口”。先找到請求進(jìn)入系統(tǒng)的入口層沿著調(diào)用鏈往下走一遍記錄每次跨模塊調(diào)用的位置。這一步做完通常就能明顯看出模塊間的真實(shí)關(guān)系與設(shè)計(jì)時(shí)的預(yù)期關(guān)系差距有多大。第二優(yōu)先是看“數(shù)據(jù)流向”。搞清楚一次完整的業(yè)務(wù)操作中數(shù)據(jù)在各模塊之間如何傳遞、如何轉(zhuǎn)換、如何落庫。數(shù)據(jù)流向往往能揭示模塊劃分的合理性——如果數(shù)據(jù)在模塊之間的傳遞需要頻繁地做格式轉(zhuǎn)換說明模塊邊界的劃分跟數(shù)據(jù)的自然邊界是不吻合的。第三優(yōu)先是看“異常的歸屬”。把錯(cuò)誤處理代碼的位置梳理一遍哪些異常在哪一層捕獲的、哪些錯(cuò)誤信息是在哪一層拼裝的。錯(cuò)誤歸屬混亂是模塊職責(zé)不清的最直接證據(jù)。排查過程中我有一個(gè)習(xí)慣每記錄一個(gè)問題點(diǎn)就標(biāo)注“影響范圍”和“修復(fù)代價(jià)”兩個(gè)屬性。影響范圍指這個(gè)位置的問題會影響多少模塊修復(fù)代價(jià)指調(diào)整它需要改多少代碼。優(yōu)先處理的永遠(yuǎn)是影響范圍大但修復(fù)代價(jià)小的項(xiàng)——這類問題通常是邊界位置有點(diǎn)偏挪一下就回來了性價(jià)比特別高。有個(gè)排查中的小技巧分享給讀者排查依賴問題不要只看代碼本身的 import還要看運(yùn)行時(shí)動(dòng)態(tài)加載和配置層面的依賴。有些框架會通過反射或配置聲明模塊間關(guān)系這類依賴在靜態(tài)代碼里看不出來但結(jié)構(gòu)出問題時(shí)它們往往是隱形元兇。遇到奇怪的問題先查配置再查代碼能少走很多彎路。我個(gè)人在實(shí)際操作中體會最深的一件事是代碼結(jié)構(gòu)沒有“完美解”只有“合適解”。每個(gè)項(xiàng)目、每個(gè)團(tuán)隊(duì)、每個(gè)業(yè)務(wù)階段適合的結(jié)構(gòu)都不一樣。早期寧可簡單一點(diǎn)也別為了架構(gòu)美感引入過度抽象后期寧可干脆重構(gòu)一次也別讓腐化的結(jié)構(gòu)持續(xù)拖慢交付速度。結(jié)構(gòu)是給人維護(hù)的不是給機(jī)器跑的——像跟多年未見的同學(xué)聊天那樣去讀代碼結(jié)構(gòu)好不好感受最誠實(shí)。最后再分享一個(gè)小技巧每隔一段時(shí)間可以是每月或每季度做一次依賴圖自查。看看有沒有新增的不該有的依賴、有沒有模塊職責(zé)已經(jīng)明顯偏離、有沒有公共層被塞進(jìn)了不該放的東西。每次只要花半小時(shí)到一小時(shí)卻能提前暴露大概率會變成重構(gòu)難題的隱患。結(jié)構(gòu)維護(hù)不是什么高深莫測的事它更像打掃房間——定期做每次不累留到積灰才是大工程。