【CSDN 編者按】代碼審查是大規模軟件開發過程中的一個重要部分，占用了代碼提交人員和代碼審查員的大量時間。Google 也不例外，為此，他們采用了最近在序列模型中的先進技術，以自動解決 Google 日常開發工作流程中的代碼審查評論。

(資料圖片僅供參考)

原文地址：https://ai.googleblog.com/2023/05/resolving-code-review-comments-with-ml.html

作者 | Alexander Fr mmgen，Lera Kharatyan，谷歌核心系統和體驗團隊

譯者 | 明明如月

出品 | CSDN（ID：CSDNnews）

在代碼審查過程中，審查員會審查代碼中的問題并編寫評論要求作者進行代碼更改。在 Google，我們每年看到數百萬條審查員的評論，作者們需要花費大約 60 分鐘的時間來應對這些評論，并根據評論的文本提出代碼更改。我們研究發現，代碼作者為解決審查員評論必須付出的工作時間幾乎隨評論數量線性增長。然而，借助機器學習（ML），我們可以自動化并簡化代碼審查過程，例如，根據代碼審查評論自動給出對應的代碼變更。

今天，我們采用了最近在序列模型中的先進技術，以自動解決 Google 日常開發工作流程中的代碼審查評論（即將發布）。截止今天，Google 的工程師已經可以通過應用 ML 建議的修改來處理大量的代碼審查員評審建議。我們預計這將每年為 Google 節省數十萬小時的代碼審查時間。我們收到了很多非常積極的反饋，說明了機器學習建議的代碼修改確實提高了 Google 開發人員的生產力 , 能夠讓他們專注于更有創造力和復雜的任務。

預測代碼修改

我們首先訓練了一個模型來預測解決評論所需的代碼修改。該模型在各種編碼任務和相關的開發者活動 ( 例如 , 重命名一個變量 , 解決構建過程中的錯誤 , 編輯一個文件 ) 上進行了預訓練。然后，使用審查過的代碼修改、審查員的評論以及作者執行的解決這些評論的修改，對該模型進行特定任務的微調。

這是一個基于 ML 建議進行代碼重構的一個實例

Google 使用一個單體倉庫（monorepo），這是一種源代碼管理策略，所有的代碼和資源都存儲在同一個倉庫中，而不是分散在多個倉庫中。這種策略有許多優點，包括代碼共享和重用、大規模重構、協作和依賴管理等。這使得我們的訓練數據集能夠包含用于構建 Google 最新軟件及其之前版本的海量代碼。

為了改進模型質量，我們不斷迭代訓練數據集。例如，我們比較了包含每個文件的單個審查員評論的數據集與每個文件的多個評論的數據集的模型性能，并使用分類器根據一個小型、精心策劃的數據集來清理訓練數據，以選擇具有最佳離線精度和召回率指標的模型。

服務基礎設施和用戶體驗

我們在訓練好的模型的基礎上設計和實現了這個功能，重點關注整體用戶體驗和開發者效率。作為其中一部分，我們通過一系列用戶研究，探索了不同的用戶體驗（UX）替代方案。然后，我們根據來自內部測試版（即，開發中的功能測試）的洞察，包括用戶反饋（例如，在建議的編輯旁邊 加入 " 這有幫助嗎？（Was this helpful）" 按鈕），對功能進行了優化。

最終的模型被校準為目標 準確率為 50%。也就是說，我們調整了模型和建議過濾，以使我們的評估數據集中 50% 的建議修改是正確的。一般來說，提高目標準確率會減少顯示的建議編輯的數量，降低目標準確率會導致更多的錯誤建議編輯。錯誤的建議編輯會占用開發者的時間，降低開發者對該功能的信任。我們發現，目標準確率為 50% 提供了一個良好的平衡。

在較高層次上，對于每個新的審查員評論，我們以與訓練相同的格式生成模型輸入，查詢模型，并生成建議的代碼修改。如果模型對預測有信心，并且滿足了一些額外的啟發式規則，我們就會將建議的修改發送到下游系統。下游系統，即代碼審查前端和集成開發環境（IDE），向用戶展示建議的編輯，并記錄用戶交互，如預覽和應用事件。一個專門的管道收集這些日志，并生成匯總洞察，例如，本博客文章中報告的總體接受率。

ML 建議編輯（ML-suggested edits）基礎設施的架構。我們處理來自多個服務的代碼和基礎設施，獲取模型預測并在代碼審查工具和 IDE 中顯示預測結果

開發者在代碼審查工具和 IDE 中與 ML 建議的編輯進行交互。根據用戶研究的洞察，集成到代碼審查工具中最適合于流線型的審查體驗。IDE 集成提供了額外的功能，并支持在審查過的代碼狀態（右圖）上有沖突的本地更改情況下，對 ML 建議的編輯（左圖）進行三方合并，合并到合并結果（中圖）。

IDE 中的三向合并的演示

結果

離線評估表明，模型以 50% 的目標精確度解決了 52% 的評論。測試版和完整內部發布的在線指標確認了這些離線指標，也就是說，我們看到約 50% 的所有相關審查員評論上，模型建議的信心超過了我們的目標模型信心。代碼作者應用了所有預覽過的建議編輯的 40% 到 50%。

在測試版期間，我們利用 " 沒有幫助（not helpful）" 的反饋來識別模型的常見失敗模式。我們實施了服務時間啟發式規則來過濾這些，并因此減少了顯示的錯誤預測的數量。通過這些更改，我們用質量換取了數量，并觀察到現實世界接受率的增加。我們的測試版推出顯示出一個潛在的問題：代碼作者只預覽了約所有生成的建議編輯的 20%。我們優化了用戶體驗，在審查員評論旁邊引入了一個顯眼的 " 顯示 ML 編輯（Show ML-edit）" 按鈕（參見上圖），在發布時的總預覽率約提升到了 40%。我們還發現，由于作者在審查過程中進行了沖突的更改，代碼審查工具中的建議編輯經常不適用。我們用一個按鈕解決了這個問題，這個按鈕在代碼審查工具中打開了一個合并視圖，用于建議的編輯。我們現在觀察到，這些中有超過 70% 的在代碼審查工具中應用，不到 30% 的在 IDE 中應用。所有這些改變使我們能夠將采用 ML 建議編輯解決的審查員評論的總體比例增加了兩倍，從測試版到完全內部發布。在 Google 可以幫助我們每年自動解決幾十萬條評論。建議過濾漏斗

我們看到 ML 建議的編輯在生產中解決了審查員評論的廣泛范圍。這包括簡單的局部重構和在代碼中分散的重構，如上述博客文章中的示例所示。該功能解決了需要代碼生成、重構和導入的較長和非正式措辭的評論。

一個需要代碼生成、重構和導入的較長且代碼評審建議的示例

模型也可以回應復雜的評論并產生較大范圍的代碼修改（如下所示）。生成的測試案例遵循現有的單元測試模式，同時更改評論中描述的細節。此外，編輯建議了一個全面的測試名稱，反映了測試的語義。

模型回應復雜評論并生成大量代碼修改的能力的示例

結論和未來工作

在這篇文章中，我們介紹了一個機器學習（ ML）輔助功能，以減少在代碼審查相關修改上花費的時間。目前，在 Google 使用的編程語言中，大量的所有可操作的代碼審查評論都可以通過應用 ML 建議的編輯來解決。我們將在所有 Google 開發人員中進行的為期 12 周的 A/B 實驗將進一步衡量該功能對整體開發者生產力的影響。

我們正在全面優化整個技術棧。這包括提高模型的質量和召回率，給開發者提供更流暢的使用體驗，通過改進發現性（提供清晰的界面和導航，以幫助用戶快速找到他們所需的功能，而無需花費過多的時間和精力）來提升整個審查過程的體驗。作為其中的一部分，我們正在研究在審查員草擬評論時顯示 ML 建議的編輯的功能，并將功能集成到 IDE 中，以便代碼變更的作者能夠在獲取審查人員的描述時就可以獲得 ML 的代碼修改建議。

致謝

這是 Google 核心系統和體驗團隊、Google Research 和 DeepMind 的許多人的共同研究成果。我們特別感謝 Peter Choy 為我們的合作提供支持，以及我們團隊所有成員的關鍵貢獻和有益建議，包括 Marcus Revaj、Gabriela Surita、Maxim Tabachnyk、Jacob Austin、Nimesh Ghelani、Dan Zheng、Peter Josling、Mariana Stariolo、Chris Gorgolewski、Sascha Varkevisser、Katja Gr ü nwedel、Alberto Elizondo、Tobias Welp、Paige Bailey、Pierre-Antoine Manzagol、Pascal Lamblin、Chenjie Gu、Petros Maniatis、Henryk Michalewski、Sara Wiltberger、Ambar Murillo、Satish Chandra、Madhura Dudhgaonkar、Niranjan Tulpule、Zoubin Ghahramani、Juanjo Carin、Danny Tarlow、Kevin Villela、Stoyan Nikolov、David Tattersall、Boris Bokowski、Kathy Nix、Mehdi Ghissassi、Luis C. Cobo、Yujia Li、David Choi、Krist ó f Moln á r、Vahid Meimand、Amit Patel、Brett Wiltshire、Laurent Le Brun、Mingpan Guo、Hermann Loose、Jonas Mattes、Savinee Dancs。