什么是代碼可視化？怎么實(shí)現(xiàn)代碼可視化？

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

1. 什么是代碼可視化？

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

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

場(chǎng)景 1：代碼邏輯理解困難

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

A：項(xiàng)目都有哪些功能??？項(xiàng)目入口在哪??？核心調(diào)用鏈路是啥？都有哪些下游??？這里好像循環(huán)調(diào)用了？

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

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

場(chǎng)景 3：項(xiàng)目重構(gòu)缺少抓手

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

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

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

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

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

1）基于源碼生成

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

場(chǎng)景 1：變更風(fēng)險(xiǎn)識(shí)別

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

場(chǎng)景 2：精準(zhǔn)測(cè)試

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

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

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

審核編輯：黃飛