Code Review效率低？來試試智能語法服務

簡介：在人工代碼評審（Code Review，CR）中，對于純文本形式的代碼瀏覽不可避免地將耗費大量的時間，影響CR的效率，那么有沒有更智能的方法？阿里云云效代碼智能語法服務基于云端備份的快速代碼導航服務，無須本地克隆即可在頁面體驗熟悉的定義參考快速查看跳轉功能，可大幅提升代碼評審的效率和質量，本文分享相關的技術原理與實作方法，

一 前言

代碼文本不是簡單的二維平面結構，看懂一段代碼需要反復地通過定義與參考的跳轉，才能將代碼深層次的邏輯和片段影響范圍理解透徹，純文本形式的代碼瀏覽是網頁端代碼評審的最大痛點之一，朱熹老先生常說“心不在此，則眼不看仔細，心眼既不專一，卻只漫浪誦讀，決不能記，記亦不能久也，”代碼文本扁平式地漫浪誦讀只能達到眼到、口到的境界，如果你是一個認真負責的代碼評審者，阿里云云效代碼智能語法服務一定是幫助你充分理解代碼變更，超越眼口，到達“心到”境界的功能，心既到矣，眼口豈不到乎？

那么什么是代碼智能語法服務呢？語法服務提供了基于云端備份的快速代碼導航服務，無須本地克隆即可在頁面體驗熟悉的定義參考快速查看跳轉功能，大幅提升代碼評審的效率和質量，

二 技識訓礎

阿里云云效代碼智能語法服務的底層技術是LSIF（Language Server Index Format），它是一種持久化語言的索引的圖存盤格式，通過圖的格式，表示了“代碼檔案”-> “語法智能結果”之間的事件關系，

在LSIF之前，LSP（Language Server Protocol）定義了編碼語言與各類終端代碼編輯器之前的互動協議，原先開發者需要為每一款編輯器都定義適配一種語法分析服務應用，那么M個語言要在M個代碼編輯器中使用的話需要MxN個應用，而有了LSP的出現，開發者在決議代碼語法時只需要遵循LSP協議格式，實作代碼補全、定義展示、代碼診斷等介面，就只需要開發M+N個應用，

然而代碼分析往往需要耗費大量的時間和資源，當用戶請求某個語法服務（如查看定義），后端需要克隆代碼，下載依賴包，決議語法，構建索引（類比一下IntelliJ Idea初始化工程的場景），編輯器場景用戶已經習慣于這樣的方式，等待幾分鐘或許問題不大，但CR場景或者輕量級的代碼瀏覽場景，這種方式就顯得時效性比較低了，幾分鐘后或許用戶已經完成了代碼瀏覽，而且缺少持久化的存盤會導致資源過度消耗，于是，LSIF就在這樣的背景下應運而生，秉承用空間換時間的思想，提前計算好語法分析結果以特定的索引格式存盤在云上，從而快速回應不同用戶的多次請求，

援引官方示例來簡單介紹下LSIF，如下方代碼：

// this is a sample class
public class Sample {
}

假定只有一種互動，當滑鼠移動到Sample的類名上，就會出現“this is a sample class”的注釋資訊，用LSIF的圖就可以如下描述，

一個sample檔案，包含了一個range資訊，這個range關聯了一個hoverResult，含義是該檔案的某個位置范圍內，觸發hover事件的話，就給出hoverResult存盤的結果，

如果用Json檔案描述這張圖的存盤，就可以得到如下結果：

{ id: 1, type: "vertex", label: "document", uri: "file:///abc/sample.java", languageId: "java" }
{ id: 2, type: "vertex", label: "range", start: { line: 0, character: 13}, end: { line: 0, character: 18 } }
{ id: 3, type: "edge", label: "contains", outV: 1, inVs: [2] }
{ id: 4, type: "vertex", label: "hoverResult", result: {["this is a sample class"]} }
{ id: 5, type: "edge", label: "textDocument/hover", outV: 2, inV: 4 }

實際一個工程的LSIF圖會非常復雜，經常會包含幾十萬個節點，感興趣的同學可以參考LSIF具體描述[1]，

三 實作方式

阿里云云效的語法服務架構圖主要分為兩部分：

• 基于事件觸發的索引構建程序
• 基于用戶請求的語法服務回應

1 索引構建

用戶對代碼的瀏覽場景主要集中在代碼評審和主干分支的代碼瀏覽，所以我們目前主要支持兩種場景的語法服務，語法服務接收來自代碼平臺的事件訊息，如代碼推送事件，評審的創建、更新、合并、關閉、重新開啟事件，來觸發語法服務構建，

我們的構建作業流調度主要基于阿里巴巴開源的分布式調度框架tbschedule，該系統會通過zookeeper維護一個任務集群，通過zookeeper位元組點管理和任務分發，不重復不遺漏地快速處理調度任務，

針對不同語言，我們只需要實作一次從源代碼到LSIF格式的轉換，就能將其應用在多種場景，多種代碼語言代碼語言都會被決議成統一的LSIF格式檔案，

針對阿里巴巴內部主要的Java語言，我們利用開源Java代碼決議工具Spoon[2]將Java源代碼分析為AST（抽象語法樹），然后捕捉定義和參考、定義與注釋之間的關聯，將坐標資訊、注釋內容，文本型別，所屬檔案等資訊聚合，輸出為統一的LSIF的Json格式，

開發期間修復并適配了一些lsif-java的問題，如位置范圍資訊錯亂，召回多種遺漏的高亮詞型別，適配非Maven倉庫的索引構建，同時還修復了Spoon關于無法正確決議注釋中的部分注解的問題，PR已被Spoon社區接受合并[3]，

生成lsif.json檔案后，由于這個Json檔案較大，直接由前端加載并回應請求不太合理，后期增量生成與維護難度也很大，所以我們還需要一步：將lsif.json轉化為結構化資料，從而按需回應用戶查詢請求，lsif的圖存盤格式讓人自然地聯想到用圖資料結構存盤，圖查詢的速度也比較快，然而由于索引變化迭代較快，頻繁更換的ID導致圖存盤難以適配增量方案，不同代碼庫不同語言的索引資料很難在一張圖中結構化，參考了社區的相關實踐，考慮到成本和性能，因為ES天然地適合大規模的資料存盤和索引，我們最后選擇了用ES（Elasticsearch）做結構化資料存盤，

我們將這種結構化的資料上傳到ES，然后語法服務后端服務器會基于用戶的語法請求，構造ES請求Query，查詢定義、參考或注釋資訊，將其拼裝回傳，

對于分支，我們會持續更新和保留最新版本的索引資料；對于代碼評審，我們會構建源分支的每次Push版本和源目標分支的merge-base版本的索引，

索引構建的另外一個難點是增量計算，如上文所述，語法服務索引構建對資源的要求非常高，而現實中代碼庫不可避免地會存在頻繁提交的現象，如此引申出了兩個優化點：

1. 利用增量的方式減少存盤內容的變更，加快索引構建速度，
2. 利用分布式時序鎖減少頻繁請求帶來的壓力，

增量方案

每次分支索引構建成功，我們都會在資料庫中記錄分支對應的版本號，當該分支有了一次新的提交后，在生成lsif.json后，系統會比較兩個分支的Diff，獲取到變更檔案和變更型別，通過變更檔案來進一步提取索引受到影響的檔案（參考或定義的坐標資訊變更），分析出所有受影響的檔案和對應的ES增刪操作后，完成增量索引上傳，這個增量的程序平均能減少45%的分支構建時間，

時序鎖管理

根據庫大小的區別，LSIF的索引構建時間為10秒至數分鐘不等，而用戶對同一個代碼倉庫的提交操作峰值可能會達到每分鐘近百次，即使我們采用了增量技術也很難滿足高頻的構建請求，并且提交事件觸達和調度任務執行無法保證精準的時序性，綜上所述，我們需要一個分布式時序鎖來保證任務調度的順序和盡量減少重復調度，

當同一代碼庫的不同推動訊息紛涌而至，Redis維護的分布式鎖會做如下判斷：若該庫當前沒有正在運行的任務，將任務置于隊首，立即運行；若已有一個正在執行的任務，比較新來的Push訊息是否是最新的，若是，則加入隊尾；當隊伍已有兩個成員時，則將任務丟棄，因為每次執行任務時，系統都會克隆分支代碼，基于最新的版本構建索引，如此就避免了多少次Push就需要執行多少次索引構建的可能性，考慮到執行緒意外退出的情況，隊首會每隔5秒鐘全域發送心跳，當隊尾或新來的任務監聽到心跳超時，則會將隊首的任務放棄并執行新的任務，

2 語法服務回應

如前言的示例，用戶在使用語法服務時，主要有以下三個請求：

1. 每次打開檔案獲取所有的可點擊高亮詞
2. 點擊高亮詞獲取對應的定義與參考串列
3. 點擊定義和參考實作跳轉

針對第一個請求，系統會構造基于檔案路徑的過濾條件構造ES的Query請求，將當前檔案的所有高亮詞坐標資訊發送給前端，避免了前端做語法分詞，沒有構建好的檔案自然也不會在頁面上被高亮出來，另外，為了避免超大檔案對ES的壓力，前端會做分批動態加載，

針對第二個請求，我們在獲取定義與參考串列的程序中，不光要得到檔案名和位置資訊，還需要將對應的代碼內容展示出來，方便用戶理解，為了實作這個效果，我們新增了批量獲取檔案片段的介面，

對于第三個請求，同一個檔案內的跳轉會自動高亮到對應的代碼行，不同檔案間的跳轉會新開頁面并跳轉，

語法服務回應和語法索引構建是完全異步的，互不影響，支持獨立的資源擴縮，

3 索引清理

語法服務的索引大小約是代碼檔案內容的數倍，比較消耗存盤資源，所以針對用戶通常的使用習慣和場景，制定了一系列索引清理任務來避免資源過度的損耗，

當代碼評審合并或洗掉時，當分支洗掉時，系統會開始執行索引清理任務，釋放索引資源，

四 語法服務展望

缺少符號跳轉長久以來一直是頁面上代碼閱讀的痛點之一，各種語法協議和技術層出不窮，如LSIF、Kythe、SARIF、UAST、Tree-sitter，ctags，全球技術人都在為更智能的代碼分析，更好的代碼體驗，更高的代碼質量做努力，云效語法服務后續也會逐漸加快語法構建速度，支持更多的代碼語言，滿足更多的語法場景，提升用戶的代碼瀏覽體驗，

相關鏈接

[1]https://microsoft.github.io/language-server-protocol/specifications/lsif/0.4.0/specification/
[2]http://spoon.gforge.inria.fr/
[3]https://github.com/INRIA/spoon/pull/3513

原文鏈接：https://developer.aliyun.com/article/779951?

著作權宣告：本文內容由阿里云實名注冊用戶自發貢獻，著作權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任，具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》，如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻洗掉涉嫌侵權內容，