調(diào)用關(guān)系圖插件實(shí)測(cè)：從配置到代碼重構(gòu)實(shí)戰(zhàn))
想在VSCode里把函數(shù)調(diào)用關(guān)系看清比很多人想象中要費(fèi)勁。面對(duì)一個(gè)幾百個(gè)文件的項(xiàng)目你想搞清楚某個(gè)函數(shù)到底被誰(shuí)調(diào)用了、它內(nèi)部又調(diào)了哪些函數(shù)靠肉眼翻代碼基本屬于體力活。要是你接手過(guò)老項(xiàng)目或者剛被安排去維護(hù)一套別人寫(xiě)的系統(tǒng)應(yīng)該能體會(huì)那種打開(kāi)文件、右鍵、到處搜引用的崩潰感。VSCode插件生態(tài)里有不少專門(mén)解決這個(gè)問(wèn)題的工具它們可以在一兩分鐘內(nèi)生成一張清晰的函數(shù)調(diào)用關(guān)系圖把隱藏在代碼里的依賴結(jié)構(gòu)直接鋪在你面前。這篇文章我會(huì)把我用過(guò)的幾個(gè)主流插件、具體配置方法、踩過(guò)的坑和實(shí)戰(zhàn)中的用法都整理出來(lái)給正在為代碼可讀性和重構(gòu)頭禿的同學(xué)一份可以直接上手的參考。1. 為什么要給VSCode把函數(shù)調(diào)用關(guān)系“畫(huà)出來(lái)”1.1 閱讀陌生代碼時(shí)最痛苦的環(huán)節(jié)看陌生代碼最難的不是語(yǔ)法而是“上下文”。比如你在一個(gè)入口文件里看到一個(gè)函數(shù)調(diào)用想順著它往下追就得一個(gè)個(gè)跳進(jìn)定義里再跳出來(lái)好不容易看完一條鏈路回頭又忘記剛才那個(gè)變量是怎么傳進(jìn)來(lái)的。VSCode自帶的Go to Definition和Find All References功能雖然能用但它們只能解決“單次跳轉(zhuǎn)”的問(wèn)題沒(méi)法幫你形成“整體視圖”。你在一百個(gè)文件里穿梭了半天腦子里還是拼不出這張調(diào)用網(wǎng)絡(luò)。函數(shù)調(diào)用關(guān)系插件解決的正是這個(gè)問(wèn)題它把所有函數(shù)之間的調(diào)用關(guān)系收集起來(lái)畫(huà)成一張圖。樹(shù)的根節(jié)點(diǎn)是你要分析的那個(gè)函數(shù)往下展開(kāi)的是它調(diào)用的子函數(shù)往上追溯的是所有調(diào)用它的地方。有了這張圖你不需要在編輯器里來(lái)回跳一眼就能看到這個(gè)函數(shù)在項(xiàng)目里處于什么位置、依賴鏈有多深、被哪些模塊引用。1.2 函數(shù)調(diào)用關(guān)系插件的應(yīng)用場(chǎng)景這個(gè)東西不是用來(lái)炫技的它有幾個(gè)非常實(shí)際的使用場(chǎng)景。新入職或者剛接手項(xiàng)目時(shí)先用調(diào)用關(guān)系圖把核心模塊跑一遍比直接讀文檔有效得多尤其當(dāng)文檔缺失的時(shí)候代碼本身的調(diào)用關(guān)系就是最可靠的說(shuō)明書(shū)。代碼重構(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)而不是在無(wú)關(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í)候幾乎沒(méi)有出現(xiàn)意外報(bào)錯(cuò)。那種“改一行斷一片”的事故靠這張圖完全可以避掉大多數(shù)。2. 主流VSCode函數(shù)調(diào)用關(guān)系插件實(shí)測(cè)對(duì)比2.1 Call Graph最經(jīng)典、最通用VSCode上專門(mén)做函數(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插件最吸引我的地方是它的過(guò)濾能力。你可以通過(guò)配置項(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)的開(kāi)發(fā)者使用。它唯一的缺點(diǎn)也比較明顯——需要額外安裝universal-ctags和Graphviz因?yàn)楸旧碇皇且粋€(gè)前端真正的解析和繪圖都依賴這兩個(gè)外部命令行工具。2.2 CodeGraph - Call Graph中文友好、操作直白CodeGraph - Call Graph是另一個(gè)很實(shí)用的選擇它跟前面說(shuō)的Call Graph理念相近但在交互邏輯上做了一些簡(jiǎn)化比較適合不太想折騰底層工具鏈的開(kāi)發(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用戶來(lái)說(shuō)比在終端里反復(fù)改PATH環(huán)境變量要省心。實(shí)際使用中你只需要右鍵一個(gè)函數(shù)名選擇“Show CodeGraph”或者類似入口它就會(huì)以當(dāng)前函數(shù)為根生成調(diào)用樹(shù)。樹(shù)形視圖點(diǎn)開(kāi)每個(gè)節(jié)點(diǎn)VSCode會(huì)自動(dòng)跳到對(duì)應(yīng)代碼行這種“圖跳轉(zhuǎn)”的結(jié)合體驗(yàn)特別適合在代碼閱讀時(shí)使用。而且它生成的圖樣式比較清爽沒(méi)有多余的重型裝飾屬于那種沒(méi)有學(xué)習(xí)成本、裝上就能用的插件。2.3 VSCode Code Map另一種“地圖”思路VSCode Code Map在思路上跟前面兩個(gè)不太一樣它強(qiáng)調(diào)的是“整個(gè)項(xiàng)目的依賴景觀”而不是單點(diǎn)函數(shù)調(diào)用。這個(gè)插件也能通過(guò)搜索函數(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)目來(lái)說(shuō)體驗(yàn)相當(dāng)不錯(cuò)。如果你做的是前端工程化或者微前端改造Code Map的“全局地圖”視角會(huì)比其他插件更適合因?yàn)槟憧梢钥焖倏辞宄鱾€(gè)模塊的邊界而不是糾結(jié)于單個(gè)函數(shù)的上下游。不過(guò)它的回調(diào)關(guān)系展示粒度略粗不像Call Graph那樣能細(xì)分到每個(gè)函數(shù)節(jié)點(diǎn)。我個(gè)人的選擇是日常閱讀和重構(gòu)用Call Graph需要給項(xiàng)目做模塊級(jí)盤(pán)點(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的方案高不少。它的形式是樹(shù)形列表而不是圖形化圖譜看多了視覺(jué)上會(huì)累一點(diǎn)但勝在原生穩(wěn)定、沒(méi)有外部依賴。新建一個(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很廣能接受命令行配置的開(kāi)發(fā)者CodeGraph - Call Graph圖ctags較廣想要中文界面和快速上手的人VSCode Code MapHTML/JSON地圖無(wú)語(yǔ)言依賴符號(hào)索引前端項(xiàng)目、工程化分析內(nèi)置Call Hierarchy樹(shù)形列表無(wú)語(yǔ)言服務(wù)限定想零依賴快速查詢的人選型沒(méi)有絕對(duì)的優(yōu)劣關(guān)鍵是看你的項(xiàng)目語(yǔ)言、團(tuán)隊(duì)協(xié)作方式和你愿意投入的學(xué)習(xí)成本。如果你只想“裝上就畫(huà)、畫(huà)完就跳”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)境變量沒(méi)有配置對(duì)插件會(huì)提示找不到可執(zhí)行文件。Windows用戶尤其容易遇到這個(gè)問(wèn)題后面我會(huì)在常見(jiàn)問(wèn)題里專門(mén)說(shuō)。裝好這兩個(gè)工具之后再在VSCode擴(kuò)展商店搜索“Call Graph”并安裝那個(gè)由Carlos Crespo開(kāi)發(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)前打開(kāi)的這個(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é)果有邊界、不混亂生成的圖只需要幾秒鐘就能加載出來(lái)還帶有逐層展開(kāi)的功能方便一層層深入。如果一開(kāi)始就對(duì)整個(gè)項(xiàng)目生成那種幾千個(gè)節(jié)點(diǎn)纏在一起的圖反而會(huì)讓人看暈。3.3 核心配置項(xiàng)過(guò)濾規(guī)則、深度限制、輸出格式安裝完插件后打開(kāi)VSCode的settings.json配置其實(shí)可調(diào)的東西很多。我梳理幾個(gè)最有用的參數(shù)按照新手的推薦程度排列callgraph.filter.excludedReferences排除指定引用名。比如你想忽略項(xiàng)目里大量出現(xiàn)的日志類函數(shù)調(diào)用可以在這里列出來(lái)圖會(huì)瞬間干凈很多。callgraph.graph.outputFormat輸出格式。支持svg、png、dot等。個(gè)人建議日常輸出svg縮放不模糊代碼評(píng)審貼圖也清晰。callgraph.graph.direction圖的布局方向默認(rèn)是TBTop-Bottom自上而下。如果函數(shù)樹(shù)很深改成LRLeft-Right反而更省橫向空間適合多次嵌套的調(diào)用鏈。callgraph.filter.maxDepth最大遞歸深度。有時(shí)你只想看前三級(jí)調(diào)用就可以設(shè)置一個(gè)數(shù)字防止圖無(wú)限膨脹。callgraph.filter.excludedFiles排除文件模式?？梢杂猛ㄅ浞^(guò)濾掉測(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ū)中打開(kāi)或者用插件配置里的解析器指定功能讓ctags只解析對(duì)應(yīng)語(yǔ)言的源文件排除其他目錄。Python項(xiàng)目如果用了虛擬環(huán)境建議在配置里顯式排除**/venv/**或者**/site-packages/**否則ctags會(huì)把虛擬環(huán)境里成千上萬(wàn)個(gè)第三方包的符號(hào)也掃進(jìn)來(lái)生成圖又慢又亂。C/C項(xiàng)目則要留意頭文件讓插件只分析.c、.cpp、.h、.hpp不要讓它去掃/usr/include系統(tǒng)頭文件目錄。多語(yǔ)言項(xiàng)目先做目錄隔離再分別生成各自的局部調(diào)用圖最后用模塊總覽把它們拼起來(lái)看邊界流傳關(guān)系這種從上到下、從粗到細(xì)的思路遠(yuǎn)比一次生成全局圖更靠譜。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 生成失敗或空白圖多半是依賴沒(méi)找到剛裝上Call Graph的人最容易撞見(jiàn)的情況就是點(diǎn)了生成命令后右下角彈出一個(gè)錯(cuò)誤提示說(shuō)找不到ctags或者dot或者生成了一個(gè)空白文件。這類問(wèn)題九成不是插件壞了而是外部工具安裝后沒(méi)把路徑暴露給VSCode。排查步驟如下先打開(kāi)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再試一次。不要小看這一步我見(jiàn)過(guò)很多人在這一步直接勸退實(shí)際上就是幾分鐘的配置問(wèn)題。如果插件版本比較老還會(huì)出現(xiàn)“Unable to find graphviz”這類提示解決辦法同樣是檢查dot的路徑別忽略。4.2 大項(xiàng)目卡頓圖太龐大怎么辦面對(duì)大型項(xiàng)目一次全量分析確實(shí)會(huì)很慢內(nèi)存占用飆高生成出來(lái)的圖也根本沒(mé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ì)象方法通過(guò)變量動(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)置的樹(shù)形結(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ù)上打開(kāi)Call Hierarchy把調(diào)用方列表掃一遍確認(rèn)具體代碼位置后再用Call Graph插件把根節(jié)點(diǎn)換成這個(gè)函數(shù)生成一張大圖用來(lái)觀察它在整個(gè)模塊中的傳播路徑。這樣做的好處是插件生成的圖方便宏觀分析內(nèi)置面板方便微觀定位。兩者結(jié)合以后就不會(huì)出現(xiàn)“圖很好看但不知道該點(diǎn)哪里”的尷尬了。5. 通過(guò)調(diào)用關(guān)系做代碼重構(gòu)與審查的實(shí)戰(zhàn)心得5.1 用調(diào)用圖識(shí)別“壞味道”打開(kāi)一張調(diào)用關(guān)系圖第一件事不是看圖里的樹(shù)有多深而是去關(guān)注那些特別“扎眼”的節(jié)點(diǎn)。怎么判斷扎眼一個(gè)函數(shù)被幾百個(gè)地方調(diào)用說(shuō)明它承擔(dān)了過(guò)多公共職責(zé)任何改動(dòng)都可能引發(fā)連鎖反應(yīng)這種就是典型的“上帝函數(shù)”候選。一個(gè)函數(shù)明明只應(yīng)該做一件事卻調(diào)用了七八種不同類型的操作這個(gè)函數(shù)的抽象層級(jí)也很可疑。反過(guò)來(lái)一個(gè)函數(shù)作為葉子節(jié)點(diǎn)被調(diào)用但無(wú)人引用它或者從圖中看整棵子樹(shù)孤立在外面幾乎沒(méi)有被主流程觸及那很可能就是死代碼。我習(xí)慣在代碼重構(gòu)前把兩張圖對(duì)照著看一張是某個(gè)模塊的完整調(diào)用圖另一張是只包含入口和主流程路徑的最小圖兩張之間差異過(guò)大就意味著項(xiàng)目里堆積了大量冗余路徑這些冗余路徑既是維護(hù)負(fù)擔(dān)也是未來(lái)出問(wèn)題的隱患。5.2 重構(gòu)前用調(diào)用圖做影響面分析真正動(dòng)刀改代碼之前影響面分析是剛需。我曾經(jīng)改過(guò)一個(gè)通知推送模塊的內(nèi)部函數(shù)改之前用Call Graph生成了整個(gè)模塊的上游調(diào)用圖看到那些間接引用的入口居然有七十多個(gè)而且不少藏在配置文件觸發(fā)的初始化路徑里。如果憑印象直接改大概率會(huì)漏掉某個(gè)入口。當(dāng)時(shí)我把每個(gè)上游調(diào)用點(diǎn)都拉出來(lái)過(guò)了一遍給每個(gè)調(diào)用點(diǎn)貼上三種標(biāo)簽直接依賴、間接依賴、僅初始化時(shí)引用。重構(gòu)成了兩天上線后一次意外報(bào)錯(cuò)都沒(méi)有。具體操作可以這樣先把要重構(gòu)的老函數(shù)作為根節(jié)點(diǎn)生成一張帶最大深度的上游調(diào)用圖然后逐步把每個(gè)分支的引用點(diǎn)導(dǎo)出成一個(gè)清單對(duì)照代碼逐一確認(rèn)最后標(biāo)出必須同步修改的調(diào)用方和無(wú)需改動(dòng)的白名單。這個(gè)過(guò)程看起來(lái)繁瑣但一旦養(yǎng)成習(xí)慣你寫(xiě)代碼的膽子會(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í)就要特別留心接口兼容性問(wèn)題如果上游調(diào)用方很少且封閉在一個(gè)業(yè)務(wù)模塊內(nèi)部評(píng)審重點(diǎn)就該放在局部邏輯正確性上。在寫(xiě)評(píng)審意見(jiàn)時(shí)我通常會(huì)把調(diào)用圖的關(guān)鍵區(qū)域截圖附帶在評(píng)論里幫助其他同事直觀理解影響范圍。這種方式比純文字解釋要省力很多評(píng)審的效率也明顯比逐行過(guò)代碼快。時(shí)間長(zhǎng)了我甚至?xí)髨F(tuán)隊(duì)里的重點(diǎn)重構(gòu)PR補(bǔ)一張調(diào)用圖作為附件這比什么都更能說(shuō)明改動(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)目開(kāi)始挑一個(gè)核心模塊裝好插件生成一張調(diào)用圖觀察一下那些你平時(shí)不會(huì)注意的邊緣函數(shù)。你會(huì)發(fā)現(xiàn)很多隱患其實(shí)早就畫(huà)在圖上只是你之前沒(méi)機(jī)會(huì)看到它。 VSCode函數(shù)調(diào)用關(guān)系圖插件實(shí)測(cè)：從配置到代碼重構(gòu)實(shí)戰(zhàn)
想在VSCode里把函數(shù)調(diào)用關(guān)系看清比很多人想象中要費(fèi)勁。面對(duì)一個(gè)幾百個(gè)文件的項(xiàng)目你想搞清楚某個(gè)函數(shù)到底被誰(shuí)調(diào)用了、它內(nèi)部又調(diào)了哪些函數(shù)靠肉眼翻代碼基本屬于體力活。要是你接手過(guò)老項(xiàng)目或者剛被安排去維護(hù)一套別人寫(xiě)的系統(tǒng)應(yīng)該能體會(huì)那種打開(kāi)文件、右鍵、到處搜引用的崩潰感。VSCode插件生態(tài)里有不少專門(mén)解決這個(gè)問(wèn)題的工具它們可以在一兩分鐘內(nèi)生成一張清晰的函數(shù)調(diào)用關(guān)系圖把隱藏在代碼里的依賴結(jié)構(gòu)直接鋪在你面前。這篇文章我會(huì)把我用過(guò)的幾個(gè)主流插件、具體配置方法、踩過(guò)的坑和實(shí)戰(zhàn)中的用法都整理出來(lái)給正在為代碼可讀性和重構(gòu)頭禿的同學(xué)一份可以直接上手的參考。1. 為什么要給VSCode把函數(shù)調(diào)用關(guān)系“畫(huà)出來(lái)”1.1 閱讀陌生代碼時(shí)最痛苦的環(huán)節(jié)看陌生代碼最難的不是語(yǔ)法而是“上下文”。比如你在一個(gè)入口文件里看到一個(gè)函數(shù)調(diào)用想順著它往下追就得一個(gè)個(gè)跳進(jìn)定義里再跳出來(lái)好不容易看完一條鏈路回頭又忘記剛才那個(gè)變量是怎么傳進(jìn)來(lái)的。VSCode自帶的Go to Definition和Find All References功能雖然能用但它們只能解決“單次跳轉(zhuǎn)”的問(wèn)題沒(méi)法幫你形成“整體視圖”。你在一百個(gè)文件里穿梭了半天腦子里還是拼不出這張調(diào)用網(wǎng)絡(luò)。函數(shù)調(diào)用關(guān)系插件解決的正是這個(gè)問(wèn)題它把所有函數(shù)之間的調(diào)用關(guān)系收集起來(lái)畫(huà)成一張圖。樹(shù)的根節(jié)點(diǎn)是你要分析的那個(gè)函數(shù)往下展開(kāi)的是它調(diào)用的子函數(shù)往上追溯的是所有調(diào)用它的地方。有了這張圖你不需要在編輯器里來(lái)回跳一眼就能看到這個(gè)函數(shù)在項(xiàng)目里處于什么位置、依賴鏈有多深、被哪些模塊引用。1.2 函數(shù)調(diào)用關(guān)系插件的應(yīng)用場(chǎng)景這個(gè)東西不是用來(lái)炫技的它有幾個(gè)非常實(shí)際的使用場(chǎng)景。新入職或者剛接手項(xiàng)目時(shí)先用調(diào)用關(guān)系圖把核心模塊跑一遍比直接讀文檔有效得多尤其當(dāng)文檔缺失的時(shí)候代碼本身的調(diào)用關(guān)系就是最可靠的說(shuō)明書(shū)。代碼重構(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)而不是在無(wú)關(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í)候幾乎沒(méi)有出現(xiàn)意外報(bào)錯(cuò)。那種“改一行斷一片”的事故靠這張圖完全可以避掉大多數(shù)。2. 主流VSCode函數(shù)調(diào)用關(guān)系插件實(shí)測(cè)對(duì)比2.1 Call Graph最經(jīng)典、最通用VSCode上專門(mén)做函數(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插件最吸引我的地方是它的過(guò)濾能力。你可以通過(guò)配置項(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)的開(kāi)發(fā)者使用。它唯一的缺點(diǎn)也比較明顯——需要額外安裝universal-ctags和Graphviz因?yàn)楸旧碇皇且粋€(gè)前端真正的解析和繪圖都依賴這兩個(gè)外部命令行工具。2.2 CodeGraph - Call Graph中文友好、操作直白CodeGraph - Call Graph是另一個(gè)很實(shí)用的選擇它跟前面說(shuō)的Call Graph理念相近但在交互邏輯上做了一些簡(jiǎn)化比較適合不太想折騰底層工具鏈的開(kāi)發(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用戶來(lái)說(shuō)比在終端里反復(fù)改PATH環(huán)境變量要省心。實(shí)際使用中你只需要右鍵一個(gè)函數(shù)名選擇“Show CodeGraph”或者類似入口它就會(huì)以當(dāng)前函數(shù)為根生成調(diào)用樹(shù)。樹(shù)形視圖點(diǎn)開(kāi)每個(gè)節(jié)點(diǎn)VSCode會(huì)自動(dòng)跳到對(duì)應(yīng)代碼行這種“圖跳轉(zhuǎn)”的結(jié)合體驗(yàn)特別適合在代碼閱讀時(shí)使用。而且它生成的圖樣式比較清爽沒(méi)有多余的重型裝飾屬于那種沒(méi)有學(xué)習(xí)成本、裝上就能用的插件。2.3 VSCode Code Map另一種“地圖”思路VSCode Code Map在思路上跟前面兩個(gè)不太一樣它強(qiáng)調(diào)的是“整個(gè)項(xiàng)目的依賴景觀”而不是單點(diǎn)函數(shù)調(diào)用。這個(gè)插件也能通過(guò)搜索函數(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)目來(lái)說(shuō)體驗(yàn)相當(dāng)不錯(cuò)。如果你做的是前端工程化或者微前端改造Code Map的“全局地圖”視角會(huì)比其他插件更適合因?yàn)槟憧梢钥焖倏辞宄鱾€(gè)模塊的邊界而不是糾結(jié)于單個(gè)函數(shù)的上下游。不過(guò)它的回調(diào)關(guān)系展示粒度略粗不像Call Graph那樣能細(xì)分到每個(gè)函數(shù)節(jié)點(diǎn)。我個(gè)人的選擇是日常閱讀和重構(gòu)用Call Graph需要給項(xiàng)目做模塊級(jí)盤(pán)點(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的方案高不少。它的形式是樹(shù)形列表而不是圖形化圖譜看多了視覺(jué)上會(huì)累一點(diǎn)但勝在原生穩(wěn)定、沒(méi)有外部依賴。新建一個(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很廣能接受命令行配置的開(kāi)發(fā)者CodeGraph - Call Graph圖ctags較廣想要中文界面和快速上手的人VSCode Code MapHTML/JSON地圖無(wú)語(yǔ)言依賴符號(hào)索引前端項(xiàng)目、工程化分析內(nèi)置Call Hierarchy樹(shù)形列表無(wú)語(yǔ)言服務(wù)限定想零依賴快速查詢的人選型沒(méi)有絕對(duì)的優(yōu)劣關(guān)鍵是看你的項(xiàng)目語(yǔ)言、團(tuán)隊(duì)協(xié)作方式和你愿意投入的學(xué)習(xí)成本。如果你只想“裝上就畫(huà)、畫(huà)完就跳”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)境變量沒(méi)有配置對(duì)插件會(huì)提示找不到可執(zhí)行文件。Windows用戶尤其容易遇到這個(gè)問(wèn)題后面我會(huì)在常見(jiàn)問(wèn)題里專門(mén)說(shuō)。裝好這兩個(gè)工具之后再在VSCode擴(kuò)展商店搜索“Call Graph”并安裝那個(gè)由Carlos Crespo開(kāi)發(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)前打開(kāi)的這個(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é)果有邊界、不混亂生成的圖只需要幾秒鐘就能加載出來(lái)還帶有逐層展開(kāi)的功能方便一層層深入。如果一開(kāi)始就對(duì)整個(gè)項(xiàng)目生成那種幾千個(gè)節(jié)點(diǎn)纏在一起的圖反而會(huì)讓人看暈。3.3 核心配置項(xiàng)過(guò)濾規(guī)則、深度限制、輸出格式安裝完插件后打開(kāi)VSCode的settings.json配置其實(shí)可調(diào)的東西很多。我梳理幾個(gè)最有用的參數(shù)按照新手的推薦程度排列callgraph.filter.excludedReferences排除指定引用名。比如你想忽略項(xiàng)目里大量出現(xiàn)的日志類函數(shù)調(diào)用可以在這里列出來(lái)圖會(huì)瞬間干凈很多。callgraph.graph.outputFormat輸出格式。支持svg、png、dot等。個(gè)人建議日常輸出svg縮放不模糊代碼評(píng)審貼圖也清晰。callgraph.graph.direction圖的布局方向默認(rèn)是TBTop-Bottom自上而下。如果函數(shù)樹(shù)很深改成LRLeft-Right反而更省橫向空間適合多次嵌套的調(diào)用鏈。callgraph.filter.maxDepth最大遞歸深度。有時(shí)你只想看前三級(jí)調(diào)用就可以設(shè)置一個(gè)數(shù)字防止圖無(wú)限膨脹。callgraph.filter.excludedFiles排除文件模式?？梢杂猛ㄅ浞^(guò)濾掉測(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ū)中打開(kāi)或者用插件配置里的解析器指定功能讓ctags只解析對(duì)應(yīng)語(yǔ)言的源文件排除其他目錄。Python項(xiàng)目如果用了虛擬環(huán)境建議在配置里顯式排除**/venv/**或者**/site-packages/**否則ctags會(huì)把虛擬環(huán)境里成千上萬(wàn)個(gè)第三方包的符號(hào)也掃進(jìn)來(lái)生成圖又慢又亂。C/C項(xiàng)目則要留意頭文件讓插件只分析.c、.cpp、.h、.hpp不要讓它去掃/usr/include系統(tǒng)頭文件目錄。多語(yǔ)言項(xiàng)目先做目錄隔離再分別生成各自的局部調(diào)用圖最后用模塊總覽把它們拼起來(lái)看邊界流傳關(guān)系這種從上到下、從粗到細(xì)的思路遠(yuǎn)比一次生成全局圖更靠譜。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 生成失敗或空白圖多半是依賴沒(méi)找到剛裝上Call Graph的人最容易撞見(jiàn)的情況就是點(diǎn)了生成命令后右下角彈出一個(gè)錯(cuò)誤提示說(shuō)找不到ctags或者dot或者生成了一個(gè)空白文件。這類問(wèn)題九成不是插件壞了而是外部工具安裝后沒(méi)把路徑暴露給VSCode。排查步驟如下先打開(kāi)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再試一次。不要小看這一步我見(jiàn)過(guò)很多人在這一步直接勸退實(shí)際上就是幾分鐘的配置問(wèn)題。如果插件版本比較老還會(huì)出現(xiàn)“Unable to find graphviz”這類提示解決辦法同樣是檢查dot的路徑別忽略。4.2 大項(xiàng)目卡頓圖太龐大怎么辦面對(duì)大型項(xiàng)目一次全量分析確實(shí)會(huì)很慢內(nèi)存占用飆高生成出來(lái)的圖也根本沒(mé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ì)象方法通過(guò)變量動(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)置的樹(shù)形結(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ù)上打開(kāi)Call Hierarchy把調(diào)用方列表掃一遍確認(rèn)具體代碼位置后再用Call Graph插件把根節(jié)點(diǎn)換成這個(gè)函數(shù)生成一張大圖用來(lái)觀察它在整個(gè)模塊中的傳播路徑。這樣做的好處是插件生成的圖方便宏觀分析內(nèi)置面板方便微觀定位。兩者結(jié)合以后就不會(huì)出現(xiàn)“圖很好看但不知道該點(diǎn)哪里”的尷尬了。5. 通過(guò)調(diào)用關(guān)系做代碼重構(gòu)與審查的實(shí)戰(zhàn)心得5.1 用調(diào)用圖識(shí)別“壞味道”打開(kāi)一張調(diào)用關(guān)系圖第一件事不是看圖里的樹(shù)有多深而是去關(guān)注那些特別“扎眼”的節(jié)點(diǎn)。怎么判斷扎眼一個(gè)函數(shù)被幾百個(gè)地方調(diào)用說(shuō)明它承擔(dān)了過(guò)多公共職責(zé)任何改動(dòng)都可能引發(fā)連鎖反應(yīng)這種就是典型的“上帝函數(shù)”候選。一個(gè)函數(shù)明明只應(yīng)該做一件事卻調(diào)用了七八種不同類型的操作這個(gè)函數(shù)的抽象層級(jí)也很可疑。反過(guò)來(lái)一個(gè)函數(shù)作為葉子節(jié)點(diǎn)被調(diào)用但無(wú)人引用它或者從圖中看整棵子樹(shù)孤立在外面幾乎沒(méi)有被主流程觸及那很可能就是死代碼。我習(xí)慣在代碼重構(gòu)前把兩張圖對(duì)照著看一張是某個(gè)模塊的完整調(diào)用圖另一張是只包含入口和主流程路徑的最小圖兩張之間差異過(guò)大就意味著項(xiàng)目里堆積了大量冗余路徑這些冗余路徑既是維護(hù)負(fù)擔(dān)也是未來(lái)出問(wèn)題的隱患。5.2 重構(gòu)前用調(diào)用圖做影響面分析真正動(dòng)刀改代碼之前影響面分析是剛需。我曾經(jīng)改過(guò)一個(gè)通知推送模塊的內(nèi)部函數(shù)改之前用Call Graph生成了整個(gè)模塊的上游調(diào)用圖看到那些間接引用的入口居然有七十多個(gè)而且不少藏在配置文件觸發(fā)的初始化路徑里。如果憑印象直接改大概率會(huì)漏掉某個(gè)入口。當(dāng)時(shí)我把每個(gè)上游調(diào)用點(diǎn)都拉出來(lái)過(guò)了一遍給每個(gè)調(diào)用點(diǎn)貼上三種標(biāo)簽直接依賴、間接依賴、僅初始化時(shí)引用。重構(gòu)成了兩天上線后一次意外報(bào)錯(cuò)都沒(méi)有。具體操作可以這樣先把要重構(gòu)的老函數(shù)作為根節(jié)點(diǎn)生成一張帶最大深度的上游調(diào)用圖然后逐步把每個(gè)分支的引用點(diǎn)導(dǎo)出成一個(gè)清單對(duì)照代碼逐一確認(rèn)最后標(biāo)出必須同步修改的調(diào)用方和無(wú)需改動(dòng)的白名單。這個(gè)過(guò)程看起來(lái)繁瑣但一旦養(yǎng)成習(xí)慣你寫(xiě)代碼的膽子會(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í)就要特別留心接口兼容性問(wèn)題如果上游調(diào)用方很少且封閉在一個(gè)業(yè)務(wù)模塊內(nèi)部評(píng)審重點(diǎn)就該放在局部邏輯正確性上。在寫(xiě)評(píng)審意見(jiàn)時(shí)我通常會(huì)把調(diào)用圖的關(guān)鍵區(qū)域截圖附帶在評(píng)論里幫助其他同事直觀理解影響范圍。這種方式比純文字解釋要省力很多評(píng)審的效率也明顯比逐行過(guò)代碼快。時(shí)間長(zhǎng)了我甚至?xí)髨F(tuán)隊(duì)里的重點(diǎn)重構(gòu)PR補(bǔ)一張調(diào)用圖作為附件這比什么都更能說(shuō)明改動(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)目開(kāi)始挑一個(gè)核心模塊裝好插件生成一張調(diào)用圖觀察一下那些你平時(shí)不會(huì)注意的邊緣函數(shù)。你會(huì)發(fā)現(xiàn)很多隱患其實(shí)早就畫(huà)在圖上只是你之前沒(méi)機(jī)會(huì)看到它。