想在VSCode里把函數(shù)調(diào)用關(guān)系看清比很多人想象中要費(fèi)勁。面對(duì)一個(gè)幾百個(gè)文件的項(xiàng)目你想搞清楚某個(gè)函數(shù)到底被誰(shuí)調(diào)用了、它內(nèi)部又調(diào)了哪些函數(shù)靠肉眼翻代碼基本屬于體力活。要是你接手過老項(xiàng)目或者剛被安排去維護(hù)一套別人寫的系統(tǒng)應(yīng)該能體會(huì)那種打開文件、右鍵、到處搜引用的崩潰感。VSCode插件生態(tài)里有不少專門解決這個(gè)問題的工具它們可以在一兩分鐘內(nèi)生成一張清晰的函數(shù)調(diào)用關(guān)系圖把隱藏在代碼里的依賴結(jié)構(gòu)直接鋪在你面前。這篇文章我會(huì)把我用過的幾個(gè)主流插件、具體配置方法、踩過的坑和實(shí)戰(zhàn)中的用法都整理出來給正在為代碼可讀性和重構(gòu)頭禿的同學(xué)一份可以直接上手的參考。1. 為什么要給VSCode把函數(shù)調(diào)用關(guān)系“畫出來”1.1 閱讀陌生代碼時(shí)最痛苦的環(huán)節(jié)看陌生代碼最難的不是語(yǔ)法而是“上下文”。比如你在一個(gè)入口文件里看到一個(gè)函數(shù)調(diào)用想順著它往下追就得一個(gè)個(gè)跳進(jìn)定義里再跳出來好不容易看完一條鏈路回頭又忘記剛才那個(gè)變量是怎么傳進(jìn)來的。VSCode自帶的Go to Definition和Find All References功能雖然能用但它們只能解決“單次跳轉(zhuǎn)”的問題沒法幫你形成“整體視圖”。你在一百個(gè)文件里穿梭了半天腦子里還是拼不出這張調(diào)用網(wǎng)絡(luò)。函數(shù)調(diào)用關(guān)系插件解決的正是這個(gè)問題它把所有函數(shù)之間的調(diào)用關(guān)系收集起來畫成一張圖。樹的根節(jié)點(diǎn)是你要分析的那個(gè)函數(shù)往下展開的是它調(diào)用的子函數(shù)往上追溯的是所有調(diào)用它的地方。有了這張圖你不需要在編輯器里來回跳一眼就能看到這個(gè)函數(shù)在項(xiàng)目里處于什么位置、依賴鏈有多深、被哪些模塊引用。1.2 函數(shù)調(diào)用關(guān)系插件的應(yīng)用場(chǎng)景這個(gè)東西不是用來炫技的它有幾個(gè)非常實(shí)際的使用場(chǎng)景。新入職或者剛接手項(xiàng)目時(shí)先用調(diào)用關(guān)系圖把核心模塊跑一遍比直接讀文檔有效得多尤其當(dāng)文檔缺失的時(shí)候代碼本身的調(diào)用關(guān)系就是最可靠的說明書。代碼重構(gòu)前你想改動(dòng)一個(gè)內(nèi)部函數(shù)必須提前判斷它會(huì)影響到多少外部調(diào)用如果改的是被幾百處引用的公共函數(shù)盲目動(dòng)手就是在給自己埋雷。代碼審查時(shí)評(píng)審者可以快速判斷某次改動(dòng)的影響范圍專注于真正的風(fēng)險(xiǎn)點(diǎn)而不是在無關(guān)代碼里浪費(fèi)時(shí)間。性能排查也一樣調(diào)用關(guān)系圖能幫你找出那些被高頻調(diào)用的深層函數(shù)很多時(shí)候性能瓶頸就藏在這些不起眼的葉子節(jié)點(diǎn)里。我自己用得最頻繁的場(chǎng)景是重構(gòu)。有一回我負(fù)責(zé)把項(xiàng)目里一個(gè)老舊的用戶狀態(tài)模塊拆分成獨(dú)立服務(wù)改動(dòng)前先用調(diào)用關(guān)系插件把涉及到的所有引用點(diǎn)導(dǎo)成圖按調(diào)用層級(jí)排了個(gè)優(yōu)先級(jí)再對(duì)照?qǐng)D逐個(gè)確認(rèn)調(diào)用方的依賴方式最后拆的時(shí)候幾乎沒有出現(xiàn)意外報(bào)錯(cuò)。那種“改一行斷一片”的事故靠這張圖完全可以避掉大多數(shù)。2. 主流VSCode函數(shù)調(diào)用關(guān)系插件實(shí)測(cè)對(duì)比2.1 Call Graph最經(jīng)典、最通用VSCode上專門做函數(shù)調(diào)用關(guān)系的插件不少最值得先提的是Call Graph。這個(gè)插件在命令行面板輸入Call Graph: Generate Function Call Graph就會(huì)進(jìn)入分析流程核心引擎用的是universal-ctags所以支持的語(yǔ)言范圍很廣從C、C、Java、Python到Go、PHP、Rust都有對(duì)應(yīng)的解析支持。它生成的是Graphviz格式的調(diào)用圖默認(rèn)輸出為SVG或者PNG圖片也可以直接導(dǎo)出DOT源碼繼續(xù)深化處理。Call Graph插件最吸引我的地方是它的過濾能力。你可以通過配置項(xiàng)只分析當(dāng)前文件、只分析當(dāng)前符號(hào)、排除某個(gè)測(cè)試目錄、限制遞歸層數(shù)這些在小項(xiàng)目和大型項(xiàng)目之間切換時(shí)非常有用。它還允許你為不同的編程語(yǔ)言指定各自的ctags命令行為靈活性相當(dāng)高適合有多語(yǔ)言項(xiàng)目經(jīng)驗(yàn)的開發(fā)者使用。它唯一的缺點(diǎn)也比較明顯——需要額外安裝universal-ctags和Graphviz因?yàn)楸旧碇皇且粋€(gè)前端真正的解析和繪圖都依賴這兩個(gè)外部命令行工具。2.2 CodeGraph - Call Graph中文友好、操作直白CodeGraph - Call Graph是另一個(gè)很實(shí)用的選擇它跟前面說的Call Graph理念相近但在交互邏輯上做了一些簡(jiǎn)化比較適合不太想折騰底層工具鏈的開發(fā)者。這個(gè)插件在VSCode擴(kuò)展市場(chǎng)里的名字就是CodeGraph - Call Graph關(guān)鍵優(yōu)勢(shì)是它對(duì)中文路徑和多級(jí)子目錄的支持更穩(wěn)定解析速度也還不錯(cuò)。它使用ctags引擎同時(shí)允許你直接在插件設(shè)置里填入ctags可執(zhí)行文件的路徑對(duì)Windows用戶來說比在終端里反復(fù)改PATH環(huán)境變量要省心。實(shí)際使用中你只需要右鍵一個(gè)函數(shù)名選擇“Show CodeGraph”或者類似入口它就會(huì)以當(dāng)前函數(shù)為根生成調(diào)用樹。樹形視圖點(diǎn)開每個(gè)節(jié)點(diǎn)VSCode會(huì)自動(dòng)跳到對(duì)應(yīng)代碼行這種“圖跳轉(zhuǎn)”的結(jié)合體驗(yàn)特別適合在代碼閱讀時(shí)使用。而且它生成的圖樣式比較清爽沒有多余的重型裝飾屬于那種沒有學(xué)習(xí)成本、裝上就能用的插件。2.3 VSCode Code Map另一種“地圖”思路VSCode Code Map在思路上跟前面兩個(gè)不太一樣它強(qiáng)調(diào)的是“整個(gè)項(xiàng)目的依賴景觀”而不是單點(diǎn)函數(shù)調(diào)用。這個(gè)插件也能通過搜索函數(shù)符號(hào)生成調(diào)用圖但它更擅長(zhǎng)把項(xiàng)目?jī)?nèi)各種符號(hào)函數(shù)、類、接口之間的關(guān)系做成一張可交互的HTML地圖并且可以導(dǎo)出為JSON數(shù)據(jù)方便后續(xù)二次分析。早期版本受限于VSCode內(nèi)置符號(hào)索引在某些語(yǔ)言上表現(xiàn)一般但對(duì)JavaScript、TypeScript項(xiàng)目來說體驗(yàn)相當(dāng)不錯(cuò)。如果你做的是前端工程化或者微前端改造Code Map的“全局地圖”視角會(huì)比其他插件更適合因?yàn)槟憧梢钥焖倏辞宄鱾€(gè)模塊的邊界而不是糾結(jié)于單個(gè)函數(shù)的上下游。不過它的回調(diào)關(guān)系展示粒度略粗不像Call Graph那樣能細(xì)分到每個(gè)函數(shù)節(jié)點(diǎn)。我個(gè)人的選擇是日常閱讀和重構(gòu)用Call Graph需要給項(xiàng)目做模塊級(jí)盤點(diǎn)時(shí)切換Code Map。2.4 別忘了VSCode內(nèi)置的Call Hierarchy額外提一個(gè)容易被忽略的點(diǎn)VSCode其實(shí)自帶了一部分函數(shù)調(diào)用關(guān)系能力。在TypeScript、Java、C#、PHP等語(yǔ)言里右鍵函數(shù)名選擇“Show Call Hierarchy”可以呼出一個(gè)面板同時(shí)展示“Callers”誰(shuí)調(diào)用了這個(gè)函數(shù)和“Callees”這個(gè)函數(shù)調(diào)用了誰(shuí)。這個(gè)功能不需要裝任何插件而且用的是語(yǔ)言服務(wù)自己的符號(hào)分析準(zhǔn)確度比依賴ctags的方案高不少。它的形式是樹形列表而不是圖形化圖譜看多了視覺上會(huì)累一點(diǎn)但勝在原生穩(wěn)定、沒有外部依賴。新建一個(gè)項(xiàng)目看代碼時(shí)我會(huì)優(yōu)先試試內(nèi)置Call Hierarchy搞不定再上插件。內(nèi)嵌功能的好處是零配置、跨平臺(tái)、實(shí)時(shí)同步。它和第三方插件并不沖突可以同時(shí)安裝互為補(bǔ)充。2.5 選型對(duì)比表與建議方案圖形化外部依賴多語(yǔ)言支持適合人群Call Graph插件圖universal-ctags Graphviz很廣能接受命令行配置的開發(fā)者CodeGraph - Call Graph圖ctags較廣想要中文界面和快速上手的人VSCode Code MapHTML/JSON地圖無語(yǔ)言依賴符號(hào)索引前端項(xiàng)目、工程化分析內(nèi)置Call Hierarchy樹形列表無語(yǔ)言服務(wù)限定想零依賴快速查詢的人選型沒有絕對(duì)的優(yōu)劣關(guān)鍵是看你的項(xiàng)目語(yǔ)言、團(tuán)隊(duì)協(xié)作方式和你愿意投入的學(xué)習(xí)成本。如果你只想“裝上就畫、畫完就跳”CodeGraph - Call Graph更貼心如果你追求最大程度的可控性和語(yǔ)言覆蓋面Call Graph插件加上自己維護(hù)的ctags配置才是完全體。3. 實(shí)操用Call Graph插件快速生成函數(shù)調(diào)用關(guān)系3.1 安裝前置依賴universal-ctags和Graphviz直接用Call Graph插件之前得先把兩個(gè)工具裝好否則點(diǎn)擊生成會(huì)直接報(bào)錯(cuò)而且錯(cuò)誤提示比較生硬。第一步是安裝universal-ctags。Windows用戶可以用包管理器比如在Git Bash或者WSL里執(zhí)行winget install universal-ctagsmacOS用戶執(zhí)行brew install universal-ctagsLinux發(fā)行版比較齊全Debian/Ubuntu用sudo apt install universal-ctagsCentOS/RHEL需要從源碼編譯或者使用EPEL倉(cāng)庫(kù)。安裝完成后在終端執(zhí)行ctags --version能看到Universal Ctags的版本信息就算成功了。第二步是安裝Graphviz。這個(gè)工具負(fù)責(zé)把DOT文件渲染成圖片你可以去Graphviz官網(wǎng)下載對(duì)應(yīng)平臺(tái)的安裝包也可以用包管理器裝。裝完后測(cè)試一下dot -V命令確保能輸出版本號(hào)。這里有個(gè)關(guān)鍵點(diǎn)Call Graph插件在VSCode里運(yùn)行時(shí)會(huì)去PATH里找ctags和dot兩個(gè)命令如果你的環(huán)境變量沒有配置對(duì)插件會(huì)提示找不到可執(zhí)行文件。Windows用戶尤其容易遇到這個(gè)問題后面我會(huì)在常見問題里專門說。裝好這兩個(gè)工具之后再在VSCode擴(kuò)展商店搜索“Call Graph”并安裝那個(gè)由Carlos Crespo開發(fā)的插件安裝后最好重啟一次編輯器讓插件正確識(shí)別新加入的PATH環(huán)境變量。3.2 三種生成方式從當(dāng)前文件、從當(dāng)前函數(shù)、整個(gè)項(xiàng)目Call Graph的使用入口集中在命令面板快捷鍵是CtrlShiftP。輸入Call Graph后會(huì)看到幾個(gè)不同的命令Call Graph: Generate Function Call Graph from Entire Project從項(xiàng)目根目錄出發(fā)分析所有的源文件。適合項(xiàng)目規(guī)模不大、文件數(shù)量幾百個(gè)以內(nèi)的場(chǎng)景。Call Graph: Generate Function Call Graph from Current File只分析當(dāng)前打開的這個(gè)文件。這種方式生成速度最快適合單文件內(nèi)函數(shù)關(guān)系梳理。Call Graph: Generate Function Call Graph from Current Symbol以光標(biāo)所在的函數(shù)為根節(jié)點(diǎn)分析它調(diào)用的下游函數(shù)以及它的上游調(diào)用者。這是我最常用的方式因?yàn)樗芸焖倬劢沟揭粋€(gè)函數(shù)的影響面。我日常嘗試最多的是先定位到某個(gè)可疑函數(shù)右鍵選擇從當(dāng)前符號(hào)生成調(diào)用圖。這么做的好處是結(jié)果有邊界、不混亂生成的圖只需要幾秒鐘就能加載出來還帶有逐層展開的功能方便一層層深入。如果一開始就對(duì)整個(gè)項(xiàng)目生成那種幾千個(gè)節(jié)點(diǎn)纏在一起的圖反而會(huì)讓人看暈。3.3 核心配置項(xiàng)過濾規(guī)則、深度限制、輸出格式安裝完插件后打開VSCode的settings.json配置其實(shí)可調(diào)的東西很多。我梳理幾個(gè)最有用的參數(shù)按照新手的推薦程度排列callgraph.filter.excludedReferences排除指定引用名。比如你想忽略項(xiàng)目里大量出現(xiàn)的日志類函數(shù)調(diào)用可以在這里列出來圖會(huì)瞬間干凈很多。callgraph.graph.outputFormat輸出格式。支持svg、png、dot等。個(gè)人建議日常輸出svg縮放不模糊代碼評(píng)審貼圖也清晰。callgraph.graph.direction圖的布局方向默認(rèn)是TBTop-Bottom自上而下。如果函數(shù)樹很深改成LRLeft-Right反而更省橫向空間適合多次嵌套的調(diào)用鏈。callgraph.filter.maxDepth最大遞歸深度。有時(shí)你只想看前三級(jí)調(diào)用就可以設(shè)置一個(gè)數(shù)字防止圖無限膨脹。callgraph.filter.excludedFiles排除文件模式?？梢杂猛ㄅ浞^濾掉測(cè)試文件、構(gòu)建產(chǎn)物和第三方庫(kù)。我的一般做法是全局排除**/test/**、**/build/**和**/node_modules/**不排除日志類函數(shù)但要是有某個(gè)裝飾器或者工具函數(shù)實(shí)在干擾判斷再臨時(shí)加進(jìn)排除列表。圖生成后盡量先存一份原始DOT源碼因?yàn)楹笃谙胛⒄{(diào)顏色、合并節(jié)點(diǎn)或者導(dǎo)入其他工具繼續(xù)分析時(shí)DOT源文件比PNG圖片靈活太多了。3.4 多項(xiàng)目、多語(yǔ)言的混合處理如果你手里是一個(gè)前后端混合項(xiàng)目前端是TypeScript后端是Python還有一個(gè)C的公共庫(kù)那直接把整個(gè)項(xiàng)目目錄交給Call Graph效果多半會(huì)亂。這時(shí)候建議用錯(cuò)誤思路里最常出現(xiàn)的操作反面——先按目錄拆分再逐個(gè)分析。你可以為每種語(yǔ)言單獨(dú)在一個(gè)干凈的VSCode工作區(qū)中打開或者用插件配置里的解析器指定功能讓ctags只解析對(duì)應(yīng)語(yǔ)言的源文件排除其他目錄。Python項(xiàng)目如果用了虛擬環(huán)境建議在配置里顯式排除**/venv/**或者**/site-packages/**否則ctags會(huì)把虛擬環(huán)境里成千上萬個(gè)第三方包的符號(hào)也掃進(jìn)來生成圖又慢又亂。C/C項(xiàng)目則要留意頭文件讓插件只分析.c、.cpp、.h、.hpp不要讓它去掃/usr/include系統(tǒng)頭文件目錄。多語(yǔ)言項(xiàng)目先做目錄隔離再分別生成各自的局部調(diào)用圖最后用模塊總覽把它們拼起來看邊界流傳關(guān)系這種從上到下、從粗到細(xì)的思路遠(yuǎn)比一次生成全局圖更靠譜。4. 常見問題與排查技巧實(shí)錄4.1 生成失敗或空白圖多半是依賴沒找到剛裝上Call Graph的人最容易撞見的情況就是點(diǎn)了生成命令后右下角彈出一個(gè)錯(cuò)誤提示說找不到ctags或者dot或者生成了一個(gè)空白文件。這類問題九成不是插件壞了而是外部工具安裝后沒把路徑暴露給VSCode。排查步驟如下先打開VSCode的終端分別執(zhí)行ctags --version和dot -V看看能不能正常輸出。如果終端能運(yùn)行而插件仍然報(bào)錯(cuò)很可能是VSCode進(jìn)程啟動(dòng)時(shí)PATH和終端的不一樣。這時(shí)需要在插件的設(shè)置項(xiàng)里手動(dòng)指定兩個(gè)可執(zhí)行文件的絕對(duì)路徑。比如Windows下可以在callgraph.ctags.path里填C:\Program Files\universal-ctags\ctags.exe在callgraph.graphviz.path里填C:\Program Files\Graphviz\bin\dot.exe。填完之后重啟VSCode再試一次。不要小看這一步我見過很多人在這一步直接勸退實(shí)際上就是幾分鐘的配置問題。如果插件版本比較老還會(huì)出現(xiàn)“Unable to find graphviz”這類提示解決辦法同樣是檢查dot的路徑別忽略。4.2 大項(xiàng)目卡頓圖太龐大怎么辦面對(duì)大型項(xiàng)目一次全量分析確實(shí)會(huì)很慢內(nèi)存占用飆高生成出來的圖也根本沒法看。這里我分享幾個(gè)實(shí)際有效的瘦身方案。第一不要用“Entire Project”改為“Current File”或者“Current Symbol”。如果你暫時(shí)不想深挖整張圖就先看局部。第二在配置里把callgraph.filter.excludedFiles做細(xì)該排的測(cè)試目錄和構(gòu)建目錄全排掉第三方依賴目錄堅(jiān)決清理出去。第三結(jié)合maxDepth限制層數(shù)比如設(shè)為6層之后節(jié)點(diǎn)數(shù)量會(huì)急劇下降。第四選用DOT輸出而不是SVG/PNG因?yàn)镈OT是純文本生成快渲染時(shí)再交給Graphviz按需展示。還有一個(gè)技巧是分批次生成先把核心入口函數(shù)逐個(gè)生成小圖再手動(dòng)匯總成一張大圖。這樣做雖然不能做到全自動(dòng)但能保證圖的語(yǔ)義邊界清晰比自動(dòng)生成一張幾千節(jié)點(diǎn)的蜘蛛網(wǎng)實(shí)用得多。寧要一張80個(gè)節(jié)點(diǎn)的清晰圖也不要一張8000個(gè)節(jié)點(diǎn)的亂麻。4.3 調(diào)用結(jié)果不準(zhǔn)確ctags與真實(shí)語(yǔ)義的距離ctags這個(gè)工具本質(zhì)上是基于符號(hào)掃描不是完整的語(yǔ)義分析。它識(shí)別函數(shù)定義和引用的方式主要依賴正則和語(yǔ)法特征所以它對(duì)某些語(yǔ)言和場(chǎng)景會(huì)有漏報(bào)、誤報(bào)。比如對(duì)象方法通過變量動(dòng)態(tài)調(diào)用比如Python里的裝飾器包裹比如C里的重載和模板這些都可能讓ctags產(chǎn)生偏差。如果你使用的是TypeScript或者C#這類語(yǔ)言服務(wù)很強(qiáng)的項(xiàng)目其實(shí)完全可以先嘗試內(nèi)置Call Hierarchy它對(duì)語(yǔ)義的把握要準(zhǔn)得多。Call Hierarchy只認(rèn)邏輯上的真實(shí)調(diào)用關(guān)系不受動(dòng)態(tài)分發(fā)的影響。拿到內(nèi)置的樹形結(jié)果之后再需要用圖表達(dá)時(shí)再讓ctags類插件做輔助。在動(dòng)態(tài)語(yǔ)言項(xiàng)目里ctags的結(jié)果只能當(dāng)作線索不能當(dāng)作唯一依據(jù)最終確認(rèn)還是要回到源碼里看上下文。4.4 和VSCode內(nèi)置功能的協(xié)同使用很多人在裝了調(diào)用圖插件之后就把VSCode自帶的功能全忘了這是很可惜的。內(nèi)置的Go to Definition、Find All References、Peek Definition、Breadcrumb以及Call Hierarchy其實(shí)和調(diào)用關(guān)系圖是互補(bǔ)關(guān)系。日?？焖偬D(zhuǎn)用內(nèi)置功能需要整體視角時(shí)再用插件生成的圖。我常用的組合是先在當(dāng)前函數(shù)上打開Call Hierarchy把調(diào)用方列表掃一遍確認(rèn)具體代碼位置后再用Call Graph插件把根節(jié)點(diǎn)換成這個(gè)函數(shù)生成一張大圖用來觀察它在整個(gè)模塊中的傳播路徑。這樣做的好處是插件生成的圖方便宏觀分析內(nèi)置面板方便微觀定位。兩者結(jié)合以后就不會(huì)出現(xiàn)“圖很好看但不知道該點(diǎn)哪里”的尷尬了。5. 通過調(diào)用關(guān)系做代碼重構(gòu)與審查的實(shí)戰(zhàn)心得5.1 用調(diào)用圖識(shí)別“壞味道”打開一張調(diào)用關(guān)系圖第一件事不是看圖里的樹有多深而是去關(guān)注那些特別“扎眼”的節(jié)點(diǎn)。怎么判斷扎眼一個(gè)函數(shù)被幾百個(gè)地方調(diào)用說明它承擔(dān)了過多公共職責(zé)任何改動(dòng)都可能引發(fā)連鎖反應(yīng)這種就是典型的“上帝函數(shù)”候選。一個(gè)函數(shù)明明只應(yīng)該做一件事卻調(diào)用了七八種不同類型的操作這個(gè)函數(shù)的抽象層級(jí)也很可疑。反過來一個(gè)函數(shù)作為葉子節(jié)點(diǎn)被調(diào)用但無人引用它或者從圖中看整棵子樹孤立在外面幾乎沒有被主流程觸及那很可能就是死代碼。我習(xí)慣在代碼重構(gòu)前把兩張圖對(duì)照著看一張是某個(gè)模塊的完整調(diào)用圖另一張是只包含入口和主流程路徑的最小圖兩張之間差異過大就意味著項(xiàng)目里堆積了大量冗余路徑這些冗余路徑既是維護(hù)負(fù)擔(dān)也是未來出問題的隱患。5.2 重構(gòu)前用調(diào)用圖做影響面分析真正動(dòng)刀改代碼之前影響面分析是剛需。我曾經(jīng)改過一個(gè)通知推送模塊的內(nèi)部函數(shù)改之前用Call Graph生成了整個(gè)模塊的上游調(diào)用圖看到那些間接引用的入口居然有七十多個(gè)而且不少藏在配置文件觸發(fā)的初始化路徑里。如果憑印象直接改大概率會(huì)漏掉某個(gè)入口。當(dāng)時(shí)我把每個(gè)上游調(diào)用點(diǎn)都拉出來過了一遍給每個(gè)調(diào)用點(diǎn)貼上三種標(biāo)簽直接依賴、間接依賴、僅初始化時(shí)引用。重構(gòu)成了兩天上線后一次意外報(bào)錯(cuò)都沒有。具體操作可以這樣先把要重構(gòu)的老函數(shù)作為根節(jié)點(diǎn)生成一張帶最大深度的上游調(diào)用圖然后逐步把每個(gè)分支的引用點(diǎn)導(dǎo)出成一個(gè)清單對(duì)照代碼逐一確認(rèn)最后標(biāo)出必須同步修改的調(diào)用方和無需改動(dòng)的白名單。這個(gè)過程看起來繁瑣但一旦養(yǎng)成習(xí)慣你寫代碼的膽子會(huì)大很多因?yàn)槊恳徊礁膭?dòng)都清楚知道自己踩在哪里。5.3 代碼評(píng)審時(shí)借助調(diào)用圖提高效率代碼評(píng)審時(shí)調(diào)用圖的價(jià)值主要體現(xiàn)在“快速定位風(fēng)險(xiǎn)”上。收到一個(gè)PR先別急著逐行看提交內(nèi)容用調(diào)用圖插件把新增或修改的函數(shù)作為根節(jié)點(diǎn)生成一張調(diào)用圖就能立刻看到這次改動(dòng)影響了哪些上游模塊。如果一個(gè)改動(dòng)函數(shù)的上游調(diào)用方橫跨了多個(gè)業(yè)務(wù)域評(píng)審時(shí)就要特別留心接口兼容性問題如果上游調(diào)用方很少且封閉在一個(gè)業(yè)務(wù)模塊內(nèi)部評(píng)審重點(diǎn)就該放在局部邏輯正確性上。在寫評(píng)審意見時(shí)我通常會(huì)把調(diào)用圖的關(guān)鍵區(qū)域截圖附帶在評(píng)論里幫助其他同事直觀理解影響范圍。這種方式比純文字解釋要省力很多評(píng)審的效率也明顯比逐行過代碼快。時(shí)間長(zhǎng)了我甚至?xí)髨F(tuán)隊(duì)里的重點(diǎn)重構(gòu)PR補(bǔ)一張調(diào)用圖作為附件這比什么都更能說明改動(dòng)的邊界。在我個(gè)人實(shí)際操作中的體會(huì)是函數(shù)調(diào)用關(guān)系插件最大的價(jià)值不在于生成一張漂亮的圖而在于強(qiáng)迫你在動(dòng)手前先看清依賴的全貌。閱讀代碼、重構(gòu)、評(píng)審這三件事都因?yàn)槎嗔艘粋€(gè)“空間視角”而變得踏實(shí)。建議你從這個(gè)周末的項(xiàng)目開始挑一個(gè)核心模塊裝好插件生成一張調(diào)用圖觀察一下那些你平時(shí)不會(huì)注意的邊緣函數(shù)。你會(huì)發(fā)現(xiàn)很多隱患其實(shí)早就畫在圖上只是你之前沒機(jī)會(huì)看到它。