什么是代碼可視化？怎么實現代碼可視化？

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

1. 什么是代碼可視化？

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

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

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

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

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

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

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

場景 3：項目重構缺少抓手

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

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

3. 怎么實現代碼可視化？

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

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

1）基于源碼生成

在講解使用源碼生成 CallGraph 的流程前我們先復習一下編譯原理的相關知識。

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

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

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

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

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

步驟二：使用 visit 模式獲取所有方法和調用方法信息

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

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

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

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

步驟二：使用 visit 模式獲取所有方法和調用方法信息

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

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

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

4. 有哪些應用場景？

場景 1：變更風險識別

背景：識別基礎設施變更、系統(tǒng)外部變更以及系統(tǒng)內部變更帶來的風險。

場景 2：精準測試

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

場景 3：架構守護

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

審核編輯：黃飛