作者 | 京東云開發(fā)者-京東科技 謝驍

1. 什么是代碼可視化？

Code visualizationis the process of creating graphical representations of source code to help understand and analyze it. 代碼可視化是創(chuàng)建源代碼的圖形表示以幫助理解和分析它的過程。 個人理解：通過使用圖形化手段（架構(gòu)圖、依賴圖、分布式追蹤、類圖、火焰圖、CallGraph 等）使代碼在某些特征上變得可觀測，用于輔助開發(fā)人員理解分析項目或建設(shè)一些自動化工具。

2. 為什么需要代碼可視化？

場景 1：代碼邏輯理解困難

項目代碼量很大且需求迭代快，每次梳理的文檔很快就過時了。新同學(xué)入手困難苦不堪言，老手也很難對項目整體的業(yè)務(wù)邏輯有一個全面的認(rèn)知，常常需要重新梳理邏輯。

A：項目都有哪些功能?。宽椖咳肟谠谀陌?？核心調(diào)用鏈路是啥？都有哪些下游??？這里好像循環(huán)調(diào)用了？

B：小劉的那個需求改動xx邏輯？這塊怎么和文檔上不一-樣了？誰把這塊重構(gòu)了？

?場景 2：改動影響面難以評估 需求的訴求是修改 A 頁面的邏輯，但由于后端代碼很多公用邏輯且調(diào)用層級很深，上線才后發(fā)現(xiàn)影響了 B 頁面的邏輯，造成了線上事故。

場景 3：項目重構(gòu)缺少抓手

老舊項目經(jīng)過長時間迭代和多次更換團(tuán)隊，導(dǎo)致內(nèi)部代碼邏輯十分混亂且沒人能完全講明白所有邏輯。但新的業(yè)務(wù)迭代需求源源不斷，在原有項目上修改成本越來越高，亟需重構(gòu)以獲得更高地研發(fā)效率。

? 其他場景：自動化 case 回歸常常覆蓋不到新增邏輯；線上問題排查困難，難以快速定位到出錯代碼......

3. 怎么實現(xiàn)代碼可視化？

Call Graph是程序中不同函數(shù)調(diào)用之間關(guān)系的圖形表示。它顯示了程序中的函數(shù)如何相互作用，使開發(fā)人員能夠理解程序的流程并識別潛在的性能問題。 以下講解代碼可視化的一種方式 Call Graph 的生成方案，可以分為靜態(tài)和動態(tài)分析：

3.1 靜態(tài)程序分析

1）基于源碼生成

在講解使用源碼生成 CallGraph 的流程前我們先復(fù)習(xí)一下編譯原理的相關(guān)知識。

其中編譯器前端部分主要是與源語言相關(guān)，主要包含： 詞法分析：也叫掃描（scanning），他的主要任務(wù)是從左向右逐行掃描源程序的字符，識別出各個單詞，確定單詞的類型，將識別出的單詞轉(zhuǎn)換成統(tǒng)一的機(jī)內(nèi)表示 —— 詞法單元 (token) 形式?？梢灶惐扔⒄Z字母合成單詞的過程。

語法分析：也叫解析（parsing）。語法分析器 (parser) 從詞法分析器輸出的 token 序列中識別出各類短語，從而構(gòu)造語法分析樹 (syntax tree)，并判斷源程序在結(jié)構(gòu)上是否正確?？梢灶惐葹橛⒄Z單詞組合成句子。

語義分析：使用語法樹和符號表中的信息來檢查源程序是否和語言定義的語義一致，如：類型檢查、上下文相關(guān)分析等?？梢灶惐葹闄z查英語句子是否有意義（如：Dog is cat，這種句子語法上沒問題但語義上是不對的）。它同時也收集標(biāo)識符的屬性信息，并把這些信息存放在語法樹或符號表中，以便在后面中間代碼生成過程中使用。 中間代碼：一種中間表示方式，所含信息可以推導(dǎo)出有關(guān)程序的全部事實。同一種中間代碼可以復(fù)用優(yōu)化器邏輯，并直接使用相關(guān)的編譯器后端功能，使得各環(huán)節(jié)更獨立更利于擴(kuò)展。從結(jié)構(gòu)上有圖 IR、線性 IR 和混合 IR。 編譯器后端部分主要是與目標(biāo)語言相關(guān)，包含代碼優(yōu)化器和目標(biāo)代碼生成器，這部分和生成 CG 關(guān)系不大不作更多原理闡述，有興趣的同學(xué)可以了解一下LLVM、Graalvm。

有了基本的編譯原理知識后，來看看通過源碼生產(chǎn) CG 的過程：

可以發(fā)現(xiàn)分析其實就是編譯器前端流程的復(fù)現(xiàn)，其中 AST、CFG 和 CG 都算作是圖 IR?，F(xiàn)成的源碼分析工具有Antlr/javaparser/soot 等。下面以 javaparser 工具為例簡要說明生成流程： 步驟一：導(dǎo)入需要分析項目的源碼和依賴包，并使用工具解析

步驟二：使用 visit 模式獲取所有方法和調(diào)用方法信息

步驟三：選定一個起始方法，基于方法和調(diào)用關(guān)系生成 CG 優(yōu)點：語言無關(guān)，擴(kuò)展性強(qiáng)。缺點：精度較差需要調(diào)優(yōu)；分析速度較慢；非 java 語言工具掌握有一定難度。

2）基于字節(jié)碼生成

針對語言特性進(jìn)行定制開發(fā)能夠更快獲取成果。Java 的字節(jié)碼其實也可以看做一種線性 IR，分析的流程也是類似的，同時 java 有大量的字節(jié)碼操作工具（ASM、Javaassit、bcel 等），使得字節(jié)碼解析變得很容易。 基本思路是從.class 文件中獲取類、方法簽名信息，再從字節(jié)碼中找到 invoke 指令得到調(diào)用方法簽名，基于這兩個信息就可以構(gòu)建出 CG。同時由于字節(jié)碼中包含了方法的完整簽名，因此不用像源碼分析那樣需要要引入依賴 jar 一并分析，因此在分析效率上會快很多。

下面用 bcel 工具為例簡要說明生成流程： 步驟一：解析目標(biāo)項目，可以直接使用打包好的 jar 包

步驟二：使用 visit 模式獲取所有方法和調(diào)用方法信息

步驟三：選定一個起始方法，基于方法和調(diào)用關(guān)系生成 CG 優(yōu)點：分析精確度高；解析速度快。缺點：語言相關(guān)，擴(kuò)展性差。 PS：推薦一個 idea 插件call graph，基于 idea 的psi能力實現(xiàn)，在項目代碼量不大的情況下分析還是挺精確的。

3.2 動態(tài)程序分析

也稱運(yùn)行時程序分析，一般基于 agent 方式實現(xiàn)，這里暫不展開講解，后續(xù)有機(jī)會再單獨寫一篇文章講述原理。有興趣的同學(xué)可以試用一下AppMap。

4. 有哪些應(yīng)用場景？

場景 1：變更風(fēng)險識別

背景：識別基礎(chǔ)設(shè)施變更、系統(tǒng)外部變更以及系統(tǒng)內(nèi)部變更帶來的風(fēng)險。

場景 2：精準(zhǔn)測試

背景：精準(zhǔn)測試定義為利用技術(shù)手段對測試過程產(chǎn)生的數(shù)據(jù)進(jìn)行采集存儲，計算，匯總，可視化最終幫助團(tuán)隊提升軟件測試的效率、并對項目整體質(zhì)量進(jìn)行改進(jìn)和優(yōu)化的這一系列操作。詳細(xì)的解釋可以閱讀精準(zhǔn)測試二三談。?

場景 3：架構(gòu)守護(hù)

背景：在架構(gòu)治理上，我們面對諸多挑戰(zhàn) 1）設(shè)計與實現(xiàn)不匹配。設(shè)計的軟件架構(gòu)與真正實施后的架構(gòu)，存在著巨大的差異。而這個差異，往往需要編碼上線、乃至一段時間之后才能發(fā)現(xiàn)； 2）沒有規(guī)范 / 不遵守規(guī)范。作為一個資深的開發(fā)人員，我們制定了一系列的規(guī)范，但是沒有多少團(tuán)隊人員愿意遵守； 3）代碼量巨大，難以識別問題。一個由十幾個或者幾十個微服務(wù)創(chuàng)建的系統(tǒng)，往往難以快速發(fā)現(xiàn)它們之間錯綜復(fù)雜的關(guān)系； 4）架構(gòu)模型的每個層級都可能出錯。如服務(wù)間 API 耦合、代碼間耦合、數(shù)據(jù)庫耦合等等； 5）架構(gòu)師、開發(fā)人員自身缺乏豐富的經(jīng)驗。知道有問題，但是說不出來哪有問題，也不知道如何改進(jìn)。 因此，我們需要一個平臺 / 工具，來幫助我們解決這些問題。

審核編輯：黃飛