原文地址:https://dl.acm.org/doi/10.1145/3183519.3183525

摘要

使用基於工具的輕量級程式碼檢查程式碼更改（又名現代程式碼審查）已成為廣泛的規範，應用於各種開源和產業系統。在本文中，我們對Google的現代程式碼審查進行了探索性研究。 Google很早就引入了程式碼審查並經過多年的發展；我們的研究揭示了為什麼Google引入了這種做法並分析了當前的狀態，經過數十年的程式碼變更和數百萬條程式碼稽核。透過12次訪談，對44位受訪者的調查以及分析的900萬條已稽核變更的稽核日誌，我們調查了Google進行程式碼審查的動機，當前做法，以及開發人員的滿意度和挑戰。

1.引言

對等程式碼審查，是除了作者以外的開發者們對原始碼進行手動檢查，被認為是對提高軟體專案質量的一種有價值的工具。在 1976年，Fagan正式制定了高度結構化的程式碼審查流程——程式碼檢查。多年來，研究人員提供了有關程式碼檢查的優勢的證據，特別是在發現缺陷上，但麻煩的是費時，這種方法的同步性特點阻礙了它在實踐中的推廣。現今，大多陣列織都採用更輕量級的程式碼審查實踐來限制檢查效率低下。現代程式碼審查是（1）非正式（與Fagan風格相反），（2）基於工具的，（3）非同步，（4）聚焦於審查程式碼更改。

一個開放的研究挑戰是：在這種新穎的背景下，瞭解哪些實踐代表了寶貴而有效的審查方法。 Rigby和Bird定量分析了來自跨領域軟體專案以及組織的程式碼審查資料，發現五個高度趨同的方面，他們猜想其他的專案也有這個規律性。Rigby和Bird的分析基於有價值的廣泛的觀點（分析了多個來自不同的環境的專案）。對於由Basili倡導的知識實證體系的發展，同樣重要的是要考慮對單個案例進行分析的集中和縱向的觀點。本文擴充套件了Rigby和Bird的工作，著重於審查實踐和特色，主要是：在Google成立，一家公司擁有數十年的程式碼審查的歷史和大量的每日審查借鑑。本文可以（1）對從業人員規定進行程式碼審查和（2）吸引研究人員想了解和支援這一新穎過程的人。

從Google非常早期的歷史開始，程式碼審查就已經成為軟體開發中必不可少的一部分；因為它很早就引入了，已經成為了Google文化的一個核心部分。在Google，程式碼審查的過程和工具經過反覆完善了十多年，應用在每天全球數十個辦公室中，超過25,000名開發人員的超過20,000行原始碼的更改。

我們以探索性調查形式進行分析聚焦於程式碼審查的三個方面，並擴充套件了Rigby和Bird的成果：（1）驅動程式碼審查的動機，（2）當前實踐，以及（3）開發人員對程式碼審查的感受，專注於特定審查遇到的挑戰（稽核過程中的中斷）和滿意度。我們的研究方法結合了來自多個數據源的輸入：對Google開發人員進行12次半結構化的訪談；一個內部調查，傳送給了最近做個變更審查的工程師，並收到44條回覆；一組來自兩年間的Google程式碼審查工具產生的900萬條評論的資料。

我們發現：相比其他情況，Google的流程明顯更輕鬆，基於一位審閱者，快速迭代，小更改，以及整合緊密程式碼審查工具。由於圍繞程式碼審查發生的互動是複雜的，中斷審查仍然存在。不過，開發人員認為此過程很有價值，確信當規模很大的時候，可以很好地發揮作用，並且，進行這個過程有若干原因，也取決於作者與審查者之間的關係。最後，我們發現關於使用程式碼審查工具，不僅可以協作審查，而且還有個一個很重要的發現：程式碼審查可以作為一種教學工具。

2.背景和相關工作

我們描述了文獻研究中的審查過程，然後我們詳細介紹這些融合程式碼審查的做法流程。

2.1 程式碼審查過程和情景

程式碼檢查。軟體檢查是第一個正式的程式碼審查流程。這個高度結構化的過程涉及計劃，概述，準備，檢查會議，返工和跟進。程式碼檢查的目標是在同步檢查會議中發現缺陷，作者和審稿人坐在同一會議室內來檢查程式碼更改。 Kollanus和Koskinen彙編了有關程式碼檢查的最新文獻調查研究。他們發現絕大多數關於程式碼檢查的研究本質上是經驗性的。程式碼檢查作為一種發現缺陷的技術的整體價值和促使檢查者讀程式碼的價值存在共識。總體而言，與Internet的普及和非同步程式碼審查流程的增長，自2005年以來，程式碼檢查的研究有所下降。

透過電子郵件進行非同步審查。直到2000年代後期，大多數大型OSS專案都採用一種遠端非同步審查的形式，這依賴於補丁傳送的通訊渠道，如郵件列表和問題跟蹤系統。在這種情況下，專案成員評估貢獻的補丁程式並透過這些渠道請求修改。當補丁被認為質量足夠高時，核心開發人員會將其提交給程式碼庫。受信任的提交者可能具有提交到審查過程，而不是進行提交前的審查。 Rigby等人，是最早在這種環境下進行廣泛工作的人之一；他們發現，這種型別的審查“與[程式碼檢查]幾乎沒有共同點，只是相信同行會有效地發現軟體缺陷” 。 Kononenko等人，分析了這種情況，並且發現審查響應時間和接受程度和社會因素相關，例如，審查者的工作量和改變作者的經驗，這些是程式碼檢查所無法反映的。

基於工具的審查。為了使修補程式審查的過程結構更加合理，OSS和工業設定中出現了幾種工具。這些工具支援審閱過程的持久工作：（1）補丁的作者將其提交給程式碼審閱工具，（2）審閱者可以看到建議程式碼與更改的差異，（3）可以與作者和其他審稿人就特定的話題展開討論，然後（4）作者可以提出修改意見，以解決評審者的意見。此反饋週期將持續到每個人都滿意或補丁被丟棄為止。不同的專案使用了他們的工具來支援他們的過程。 Microsoft使用CodeFlow，該工具跟蹤每個人（作者或審閱者）的狀態以及他們在程序中的位置（簽名，等待，審閱）； CodeFlow不會阻止作者未經批准而提交更改，並支援在評審執行緒中聊天。 Google的Chromium專案（以及其他幾個OSS專案）依賴於外部可用的Gerrit；在Chromium中，只有經過審閱者的明確批准並自動確認更改不會破壞構建，更改才會合併到master分支中。在Gerrit中，未分配審查者也可以發表評論。 VMware開發了開源的ReviewBoard，它將靜態分析整合到審查過程中。這種整合依賴於變更作者手動請求分析，並且已經證明可以提高程式碼審查的質量。 Facebook的程式碼審查系統Phabricator，使審查者可以“接管”更改並自行提交，並提供了掛鉤以進行自動靜態分析或持續的構建/測試整合。

在基於工具審查的背景下，研究人員調查了程式碼更改接受或響應時間與更改後的程式碼和作者的特徵之間的關係，以及審閱者之間的協議。 根據工業和OSS開發人員的意見，還進行了定義什麼構成良好的程式碼審查。

基於分叉模式的開發模型。在GitHub上，拉請求的過程中，開發人員想要對現有的git倉庫進行更改，就要對其fork進行更改。在發出拉請求後，會出現在拉請求的列表中展示專案中的問題，任何可以看到該專案的人都可以看到。 Gousios等人對拉請求整合者和貢獻者的實踐和碰到的問題進行了定性研究，發現與基於工具的程式碼審查有類似的方法。

2.2 程式碼審查中的融合實踐

Rigby和Bird提出了第一項也是最重要的工作，這些工作試圖跨幾個程式碼審查過程和上下文確定融合的實踐。 他們考慮了使用基於電子郵件審查的OSS專案，使用Gerrit的OSS專案，使用基本程式碼審查工具的AMD專案以及使用CodeFlow的Microsoft。 他們分析了這些專案的過程和資料，以描述多個角度，例如迭代開發，審查者選擇和審查討論。 他們確定了所有已考慮專案都融合到的五種現代程式碼審查實踐（表1）。 我們將使用其ID（例如CP1）來引用這些做法。 基本上，他們在快速，輕量級過程（CP1，CP2，CP3）方面達成了一致，很少有人參與（CP4）進行小組問題解決（CP5）。

3.方法論

本節描述了我們研究的問題和背景；它還概述了我們的研究方法及其侷限性。

3.1 研究的問題

這項研究的總體目標是調查Google的現代程式碼審查，這一過程涉及成千上萬的開發人員，並且經過了十多年的改進。 為此，我們進行了探索性調查，圍繞三個主要研究問題進行了結構設計。

RQ1：Google進行程式碼審查的動機是什麼？Rigby和Bird發現動機是現代程式碼審查的融合特徵之一（CP5）。 在此可以瞭解，動機和期望推動了Google的程式碼審查。 特別是，我們既考慮了引入現代程式碼審查的歷史原因（因為Google是最早使用現代程式碼審查的公司之一），也考慮了當前的期望。

RQ2：Google的程式碼審查實踐是做什麼？Rigby和Birdregard根據流程（CP1），速度和頻率（CP2），分析變更的大小（CP3）和審閱者數量（CP4）來執行流程本身。 我們對Google的這些方面進行了分析，以調查與以前的研究相比，對於具有更長程式碼審查歷史，明確文化和大量審查記錄的公司來說，同樣的發現是否成立。

RQ3：Google開發人員如何看待程式碼審查？最後，在我們的最後一個研究問題中，我們有興趣瞭解Google開發人員如何看待其公司中已實施的現代程式碼審查。為了更好的理解實踐（因為感知驅動行動）和指導未來的研究，這個探索很必需。我們聚焦於兩方面：一些特定的審查，比如：開發人員有中斷審查的經歷；在面臨一些挑戰時開發人員對審查是否滿意。

3.2 研究的背景

我們簡要描述了關於我們方法論的研究背景。 有關Google程式碼審查過程和工具的詳細說明，請參見第5.1節。

Google的大多數軟體開發都在一個整體的原始碼儲存庫中（mono-repo），透過內部版本控制系統訪問。 由於Google程式碼審查是必需的，因此，每次向Google原始碼控制系統提交程式碼，都先要使用CRITIQUE進行程式碼審查，CRITIQUE是一個內部開發的，集中的，基於Web的程式碼檢查工具。 開發工作流程基於Google的整體程式碼庫，包括程式碼審查過程，是非常統一的。就像第2節中描述的工具一樣，CRITIQUE允許審查者看到提議更改程式碼和開始討論前明確的程式碼行處。CRITIQUE提供了大量的登入功能；記錄開發者使用該工具的互動（包括開啟工具，檢視差異，建立評論和接受更改）。

3.3 研究的方法

為了回答我們的研究問題，我們採用定性和定量相結合的方法，該方法結合了以下幾種來源的資料：在與Google從事軟體開發工作的員工進行的半結構化訪談，來自程式碼審查工具的日誌以及對其他員工的調查。我們使用訪談作為一種工具來收集有關進行程式碼審查（RQ1）動機的多樣性（與頻率相對比）的資料，並激發開發人員對程式碼審查及其挑戰（RQ3）的理解。 我們使用CRITIQUE的日誌來量化和描述當前的審查實踐（RQ2）。最後，我們使用調查來確認訪談（RQ1）中出現的程式碼審查的多種動機，和激發開發人員對過程的滿意度的因素。

會談。我們與選定的Google員工進行了一系列面對面的半結構化訪談，每次訪談大約需要1個小時。最初的可能參加者是使用滾雪球取樣法來選擇的，首先是論文作者所知道的開發人員。從此庫中，選擇參與者以確保團隊的分散，技術領域，工作角色，公司內部的時間長度以及在程式碼稽核過程中的角色。訪談指令碼包括有關程式碼審查的動機，最近審查/撰寫的變更，以及最佳/最差審查經歷的問題。 在每次訪談之前，我們都會回顧參與者的審查歷史，並找到要在訪談中會討論的更改； 我們選擇這些更改，是根據互動次數，參與對話的人數，以及是否有很多令人驚訝審查點評。在訪談的觀察部分中，要求參與者在審閱即將發生的變更時思考，並提供一些明確的資訊，例如開始審閱的切入點。 訪談一直持續到達到飽和，並且訪談提出了大致相似的概念。 總體而言，我們對從Google工作1個月到10年（平均5年），軟體工程和站點可靠性工程的員工進行了12次面試。他們包括技術主管，經理和個人貢獻者。每次訪談涉及三到四個人：參與者和2-3個受訪者（其中兩個是本文的作者）。採訪由一名採訪者實時轉錄，而另一名採訪者提出問題。

採訪資料的開放編碼。為了確定採訪資料中出現的廣泛主題，我們進行了一次開放編碼。 兩位作者討論了訪談筆錄，以確立共同的主題，然後將其轉換為編碼方案。 然後，另一位作者對討論的註釋進行了封閉編碼，註釋是對確認的主題。我們對其中不止一個採訪進行了迭代，直到我們就該計劃達成協議。 我們還跟蹤了上下文（審稿人與作者之間的關係）中提到的這些主題。問題設計和分析過程的結合意味著我們可以討論結果中的穩定主題，但不能有意義地討論發生的相對頻率。

審查資料的分析。我們定量的分析資料，資料是程式碼審查過程中使用CRITIQUE產生的日誌。我們主要關注Rigby和Bird發現的融合實踐（CP）相關的指標。為了方便對比，我們不考慮沒有審查者的更改，因為我們對有明確程式碼審查過程的更改感興趣。我們將“審閱者”視為批准程式碼更改的任何使用者，而不論更改作者是否明確要求他們進行審閱。我們使用基於名稱的啟發式的方法來自動化流程產生的更改。我們專門關注Google主要程式碼庫中發生的更改。我們還排除了在研究時尚未落實的更改，以及我們的差異工具報告的原始碼零行變化量的更改，例如，僅修改二進位制檔案的更改。在Google，平均每個工作日，提交了約20,000個符合上述過濾條件的更改。 我們的最終資料集包括2014年1月至2016年7月，由25,000多名作者和審閱者建立的符合這些標準的大約900萬項更改，以及從2014年9月至2016年7月之間的所有更改中收集的大約1300萬條審查評論。

調查。我們建立了一個線上調查表，併發送給了98位最近提交了程式碼更改的工程師。程式碼更改已經過稽核，因此我們定製了調查表，以詢問受訪者如何看待程式碼稽核，關於他們最近的特定更改；這種策略使我們可以減輕召回偏見，但仍可以收集全面的資料。 該調查包括三個關於收到的評論的價值的Likertscale問題，一個關於評論對其更改影響的多項選擇（基於訪談產生的期望）和一個可選的“其他”回答，以及一個開放式- 最終提出質疑，以引起受訪者對所收到的評論，程式碼評論工具和/或整個過程的意見。 我們收到了44份有效的調查問卷答覆（45％的答覆率，在軟體工程研究中被認為很高了）。

3.4 有效性和侷限性的威脅

我們描述了研究方法所帶來的對有效性和工作成果侷限性的威脅，以及為緩解這些挑戰所採取的行動。

內部有效性——可信度。關於評論資料的定量分析，我們使用啟發式方法從定量分析中濾除機器人撰寫的更改，但這些啟發式方法可能允許某些機器人撰寫的更改； 我們對此進行了緩解，因為我們僅包括具有人工稽核者的由機器人撰寫的更改。關於定性調查，我們使用了開放式編碼來分析受訪者的答案。該編碼可能會受到編寫該編碼的作者的經驗和動機的影響，儘管會透過讓多個編碼人員參與來減輕這種偏見。決定參加我們的訪談並自由選擇調查的員工決定這樣做，從而引入了自我選擇偏見的風險。 因此，對於不選擇參與的開發人員而言，結果可能會有所不同；為減輕此問題，我們將訪談和調查中的資訊相結合。 此外，我們使用雪球抽樣方法來確定要面試的工程師，這有抽樣偏差的風險。儘管我們試圖透過面試具有各種工作角色和職責的開發人員來減輕這種風險，但我們訪談的開發人員可能有其他因素在整個公司中並不適用。 為了減輕主持人的接受偏見，參與定性資料收集的研究人員不屬於CRITIQUE團隊。 社會可取性偏見可能已經影響了答案，使其更適合Google文化。 但是，在Google鼓勵人們批評和改進發現的工作流程，從而減少這種偏見。 最後，我們沒有采訪與專家評審員（例如安全評審）進行互動的研究科學家或開發人員，因此我們的結果偏向於一般開發人員。

通用性——可移植性。我們的結果可能無法推廣到其他情況，而是我們對多年實踐和數百萬次細化檢查後，仍會發生的多種多樣的做法和審查中斷感興趣。鑑於基本程式碼檢查機制在多個公司和OSS專案中的相似性， 有理由認為，如果審查過程達到相同的成熟度並使用可比較的工具，則開發人員將具有類似的經驗。

4.結果：動力

在我們的第一個研究問題中，我們首先要研究導致這一過程的原因，從而尋求理解開發人員在Google進行程式碼審查時的動機和期望。

4.1 一切如何開始

Google的程式碼審查最早是由第一批員工之一引入的； 本文的第一作者採訪了該員工（以下簡稱 E），以更好地理解程式碼審查及其演變的最初動機。E 解釋了程式碼審查引入的主要推動力是：迫使開發人員編寫其他開發人員可以理解的程式碼 ; 這被認為很重要，因為程式碼必須作為未來開發人員的老師。Google在程式碼審查中的引入標誌著從研究程式碼庫（已最佳化為快速原型開發）向生產程式碼庫的過渡，在此基礎上考慮未來工程師閱讀原始碼。程式碼審查也被認為能夠確保不止一個人熟悉每一段程式碼，從而增加了知識在公司中的駐留機會。

E 重申了這樣一個概念，即儘管審閱者發現錯誤是很棒的，但在Google引入codereview的首要原因是為了提高程式碼的可理解性和可維護性。但是，除了最初進行程式碼審查的教育動機外，E 解釋說，開發人員的三個其他好處很快就在內部對開發人員變得顯而易見：檢查樣式和設計的一致性；確保足夠的測試；透過確保沒有任何開發人員可以在沒有監督的情況下提交任意程式碼來提高安全性。

4.2 目前的期望

透過對訪談資料進行編碼，我們確定了Google開發人員期望從程式碼審查中獲得的四個關鍵主題： 教育 ， 維護規範 ， 把關 和 事故預防 。 教育從程式碼審查中學習或學習，並與引入程式碼審查的最初原因保持一致； 規範是指組織對自由選擇的偏好（例如格式或API使用模式）; 網守涉及圍繞原始碼，設計選擇或其他工件的邊界的建立和維護； 事故是指引入錯誤，缺陷或其他與質量相關的問題。

這些是審查過程中的主要主題，但是程式碼審查也用於 追溯歷史 。開發人員在審查過程完成後對其進行評估；程式碼審查可以瀏覽歷史記錄 程式碼更改的內容，包括髮生了什麼註釋以及更改如何演變。 我們還注意到開發人員使用程式碼回顧歷史來了解錯誤的引入方式。 從本質上講，程式碼審查使將來的變更稽核成為可能。

在我們的調查中，我們進一步驗證了這種編碼方案。 他們可以選擇四個主題中的一個或多個主題和/或自己撰寫。 較早確定的四個主題中的每個主題都是在特定程式碼審查的背景下由8至11個受訪者選擇的，因此，可以更加確信上述編碼方案與開發人員對程式碼審查價值的理解相一致。

儘管這些期望可以覆蓋以前在Microsoft [4]上獲得的期望，但正如我們的參與者所解釋的那樣，Google的主要重點是教育以及程式碼的可讀性和可理解性，這與歷史動因相吻合。 因此，關注點與Rigby和Bird的關注點不一致（即，小組解決問題的活動）[33]。

發現1. Google進行程式碼審查的期望並不以解決問題為中心。 Google引入稽核，目的是確保程式碼的可讀性和可維護性。 當今的開發人員除了維護規範，跟蹤歷史記錄，保護措施和預防事故外，還從教育角度進行了瞭解。發現缺陷受到歡迎，但不是唯一的重點。

如前所述，在對訪談筆錄進行編碼時，我們還跟蹤了提到主題的評論上下文，我們發現這些不同主題的相對重要性取決於作者與評論者之間的關係（圖1）。例如，維護工程師與具有不同資歷的工程師（專案負責人，專家可讀性審閱者或“新”團隊成員）之間的規範衝突，而與同伴或其他團隊相比則少一些，而看門人和事故預防則是主要的。具有廣泛的價值，幷包含多種不同的關係。

發現2.對Google進行特定程式碼審查的期望取決於作者與審查者之間的工作關係。5.結果：實踐

在我們的第二個研究問題中，我們描述了程式碼重審過程，並將其定量方面的內容與先前工作中發現的趨同做法進行了比較[33]。

5.1 描述審查過程

Google的程式碼審查與兩個概念相關：所有權和可讀性。 我們首先介紹它們，然後描述審閱過程的流程，然後得出內部審閱工具CRITIQUE與其他審閱工具不同的特點。

所有權。Google程式碼庫以樹結構排列，其中每個目錄都由一組人員明確擁有。 儘管任何開發人員都可以提議對程式碼庫的任何部分進行更改，但是相關目錄（或父目錄）的所有者必須在提交更改之前對其進行稽核和批准； 甚至目錄所有者也要在提交之前檢查其程式碼。

可讀性。Google定義了一個稱為可讀能力的概念，該概念很早就引入了，以確保程式碼庫中的程式碼風格和規範保持一致。 開發人員可以使用特定語言獲得可讀性認證。 為了應用可讀性，開發人員將更改傳送給一組有可讀能力的審閱者。 一旦這些審閱者確信開發人員瞭解某種語言的程式碼風格和最佳實踐，便會為開發人員授予該語言的可讀性。 每次更改都必須由具有所使用語言可讀性證明的人員編寫或審閱。

2。 預覽：作者然後使用CRITIQUE來檢視更改的差異，並檢視自動程式碼分析器的結果（例如，來自Tricorder [36]）。 準備就緒後，作者將更改傳送給一個或多個審閱者。

建議審閱者。要確定最佳的人來重新審閱更改，CRITIQUE依靠一種工具來分析變更並建議可能的審閱者。 此工具確定滿足更改中所有檔案的審閱要求所需的最小審閱者集。 請注意，通常只需要一名審閱者，因為更改通常是由擁有檔案查詢所有權和/或可讀權的人創作的。 該工具對最近編輯和/或審閱所包含檔案的審閱者進行優先順序排序。 由於尚未建立新的團隊成員，因為他們尚未建立稽核/編輯歷史記錄，因此已明確新增為他們。 未分配的審閱者還可以對更改發表評論（並可能批准）。尋找審閱者的工具支援通常僅在檔案更改超出特定團隊的情況下才需要。 在一個團隊內，開發人員知道向誰傳送更改。 為了將可能傳送給團隊中任何人的更改，許多團隊使用一種系統，該系統將迴圈傳送到團隊電子郵件地址的審閱分配給配置的團隊成員，同時考慮到審閱負載和休假。

程式碼分析結果。CRITIQUE將程式碼分析結果顯示為註釋以及人工註釋（儘管顏色不同）。分析人員（或審閱者）可以提供建議的編輯，這些編輯可以被提議，也可以透過評論應用於變更。 為了在更改提交之前稽核更改，Google的開發還包括預提交掛鉤：檢查失敗需要開發人員顯式覆蓋以啟用提交的地方。 提交前檢查包括基本的自動樣式檢查和執行與變更相關的自動測試套件。 所有預提交檢查的結果在程式碼檢視工具中可見。 通常，會自動觸發預提交檢查。 這些檢查是可配置的，以便團隊可以強制實施特定於專案的不變數，並自動將電子郵件列表新增到更改中，以提高意識和透明度。 除了預先提交結果外，CRITIQUE還可以透過Tricorder [36]顯示各種自動程式碼分析的結果，這些分析可能不會阻止提交更改。 分析結果包括簡單的樣式檢查，更復雜的基於編譯器的分析透過以及特定於專案的檢查。 目前，Tricorder包括110個分析儀，其中5個是用於數百次附加檢查的外掛系統，總共可分析30多種語言。

發現3. Google程式碼稽核過程與輕量級和靈活的融合做法保持一致。 但是，與其他研究過的系統相比，所有權和可讀權是明確的，並且起著關鍵作用。 審閱工具包括審閱者推薦和程式碼分析結果。5.2 量化稽核流程

我們複製了Rigby和Bird發現的CP2-4的定量分析，以便將這些實踐與Google融合的特徵進行比較。

在Google，就頻率而言，我們發現處於中位數上的開發者每週大約進行3次更改，而80％的開發者每週進行少於7次更改。 同樣，開發人員每週稽核的變更中位數為4，而80％的審閱者每週稽核的變更少於10。 在速度方面，我們發現開發人員必須等待對其更改的初步反饋，對於較小的更改，平均時間少於一小時，對於較大的更改，平均時間少於5小時。 整個審閱過程的總體（所有程式碼大小）中值延遲小於4小時。 這比Rigby和Bird [33]報告的平均批准時間要低得多，AMD的批准時間中位數為17.5小時，Chrome OS為15.7小時，三個Microsoft專案為14.7、19.8和18.9小時。 另一項研究發現，微軟批准的平均時間為24小時[14]。

審查規模。Rigby和Bird認為，只有透過較小的變更來審查並隨後分析審查規模，才能實現快速審查時間。在Google，正在考慮的更改中，超過35％僅修改一個檔案，而大約90％的修改少於10個檔案。超過10％的更改僅修改一行程式碼，而修改的行數的中位數為24。更改位數的中位數顯著低於Rigby和Bird對AMD（44行），Lucent（263行）和Bing等公司的報告。 ，Microsoft的Office和SQLServer（在這些界限之間的某個位置），但符合開放原始碼專案中的更改大小[33]。

審查者和評論的數量。甚至在經過深入研究的程式碼檢查中，研究人員的最佳人數一直存在爭議[37]。 Rigby和Bird調查了所考慮的專案是否收斂到了類似數量的參與評審人員。 他們發現這個數字是兩個，無論是否明確邀請了審閱者（例如，在Microsoft專案中，邀請的中位數最多為4個審閱者），或者是否公開廣播了更改以進行審閱[33]。

相比之下，在Google中，只有不到25％的更改擁有多於一名審閱者，而超過99％的更改最多具有五名審閱者，中位審閱者人數為1。較大的更改通常平均會擁有更多的審閱者。 但是，即使平均變化非常大，平均也需要不到兩名審稿人。

Rigby和Bird還發現“當活躍於[超過2]位審稿人時，有關更改的評論數量最少” [33]，並得出結論，兩名審稿人發現缺陷的最佳數量。 在Google，情況有所不同：審閱人數越多，對更改的評論平均數就越多。 此外，每次更改的平均註釋數隨行數的變化而增加，對於大約1250行的更改，每個更改的最高註釋數為12.5。 大於此的更改通常包含自動生成的程式碼或較大的刪除，從而導致平均註釋數較低。

發現4.與先前調查的其他專案相比，Google的程式碼審查已將審查過程融合到一個過程中，該過程的審查速度顯著加快且變更幅度較小。 此外，與其他專案中的兩名審閱者相比，一名審閱者通常被認為足夠。6.結果：開發人員的看法

我們最後一個研究問題是透過Google的程式碼審查來調查開發人員的挑戰和滿足感。

6.1 Google的程式碼審查中斷

以前的研究調查了整個審查過程中的挑戰[4,26]，並提供了令人信服的證據，這也被我們作為工程師的經驗所證實，理解要審查的程式碼是一個主要障礙。 為了拓寬我們的經驗知識體系，我們在這裡集中討論特定審查（“審查中斷”）中遇到的挑戰，例如延誤或分歧。

對我們的訪談資料的分析提出了五個主要主題。 前四個主題認為審查中斷在過程中的相關因素有：

距離：受訪者從兩個角度感知程式碼審閱的距離：地理（即作者與審閱者之間的物理距離）和組織（例如不同團隊或不同角色之間的物理距離）。這兩種型別的距離都被認為是導致審閱過程延遲或導致誤解的原因。

社會互動：受訪者認為程式碼審閱中的交流有可能從兩個方面導致問題：措辭和權力。 措辭是指有時作者對評論發表敏感的事實。 對評論的情感分析提供了證據，表明帶有負面語氣的評論不太可能有用[11]。 權利是指使用程式碼審查過程來誘使他人改變自己的行為； 例如，拖延稽核或保留批准。 措辭或權利在審查中，可能會使開發人員對檢查過程感到不舒服或沮喪。

背景：受訪者讓我們看到，由於不知道是什麼導致了這種變化，所以會產生誤解； 例如，如果變更的理由是解決生產問題的緊急解決方案或“有個不錯的改進”。 預期結果的不匹配會導致延遲或沮喪。

最後一個主題是工具本身：

定製化：一些團隊對程式碼審查有不同的要求，例如，關於需要多少審查者。 這是技術上的審查中斷，因為批評中並不總是支援任意定製，並且可能引起對這些政策的誤解。 根據反饋，CRITIQUE最近釋出了一項新功能，該功能允許更改作者要求所有審閱者簽名。

6.2 滿意度和時間投入

為了瞭解已確定問題的重要性，我們使用了調查的一部分來調查程式碼審查是否總體上被認為是有價值的。

我們發現（表2）在Google內部程式碼審查被普遍認為是有價值和有效的–所有受訪者都同意程式碼審查很有價值的說法。我們對CRITIQUE進行的內部滿意度調查反映了這種觀點：97％的開發人員對此感到滿意。

在特定變化的背景下，情緒變化更大。最不滿意的答覆與很小的更改（1個字或2行）或與實現某些其他目標所需的更改（例如，從原始碼的更改觸發過程）相關。但是，大多數受訪者認為，他們所做的更改的反饋量是適當的。在這3箇中，有8位受訪者認為註釋無濟於事，並指出，所審查的更改是小的配置更改，對程式碼稽核沒有影響。只有2位受訪者表示評論中有bug。

badgood對於此更改，稽核過程很好地利用了我的時間24141113總的來說，我認為Google的程式碼審查很有價值0001430對於此更改，反饋量為223450

表2. 使用者滿意度調查結果

為了根據滿意度對答案進行情境化，我們還調查了開發人員花費在審閱程式碼上的時間。為了準確量化審閱者所花費的時間，我們跟蹤了開發人員與CRITIQUE的互動（例如，開啟選項卡，查看了差異，評論，批准了更改），以及其他工具來估算開發人員每週花費多長時間來稽核程式碼。我們將開發人員互動的順序分組為一定的時間段，將“審閱會話”視為與變更提交者以外的其他開發人員進行的，與同一未提交變更相關的互動順序，每次相隔不超過10分鐘。 從2016年10月開始的五週內，所有稽核會話所花的總小時數，然後計算每週每位使用者的平均值，過濾出我們在過去五週內都沒有資料的使用者。 我們發現開發人員平均花費3.2（平均每週2.6個小時）來審查更改。 與OSS專案的6.4小時/周的自我報告時間相比，這個數字很低[10]。

發現5.儘管經過了多年的改進，但Google的程式碼審查仍面對審查中斷。 這些主要與評論周圍發生的互動的複雜性有關。 但是，開發人員強烈認為程式碼審查是一個有價值的過程，開發人員每週花費大約3個小時進行審查。7.討論

我們討論了這項調查中出現的主題，這些主題可以啟發從業人員建立程式碼審查流程，並激發研究人員在未來的調查中。

7.1 真正輕量級的過程

現代程式碼審查的誕生是它減輕了繁瑣的程式碼檢查的負擔[4]； 實際上，Rigby和Bird在他們對整個系統的調查中都證實了這一特徵（CP1）。 在Google，程式碼審查已匯聚到一個更加輕量級的過程，開發人員發現該過程既有價值又可以很好地利用他們的時間。

Google的審查時間中位數比其他專案要短得多。 我們假定這些差異是由於Google在程式碼審查方面的文化（嚴格的審查標準和對快速審閱時間的期望）。 此外，審稿人人數也有很大差異（其中一個在Google中，而其他兩個在其他專案中）；我們認為擁有一名審閱者可以使審閱變得快速而輕便。

審閱時間短和審閱者人數少可能是由於程式碼審閱是開發人員工作流程中必不可少的一部分；它們也可能源於小的更改。 OSS專案的中位數變化範圍從11到32行變化，具體取決於專案。 在公司中，此更改大小通常較大，有時高達263行。 我們發現Google的更改大小與OSS更接近：大多數更改很小。變更的大小分佈是程式碼審查過程質量的重要因素。 先前的研究發現，隨著更改大小的增加，有用評論的數量會減少，審閱延遲會增加。 大小也會影響開發人員對程式碼審查過程的理解； Mozilla投稿人的調查發現，開發人員認為與大小相關的因素對稽核延遲的影響最大。 Google確認變更大小與評論質量之間的相關性，並強烈鼓勵開發人員進行小的增量更改（大刪除和自動重構除外）。 這些發現和我們的研究支援審查小的更改的價值以及對研究和工具的需求，以幫助開發人員建立如此小的獨立程式碼更改以進行審查。

7.2 實踐中的軟體工程研究

Google進行程式碼審查的部分做法與軟體工程研究中提出的做法保持一致。 例如，微軟公司對程式碼所有權的一項研究發現，應認真審查較小貢獻者所做的更改，以提高程式碼質量。 我們發現，此概念是在Google上透過要求所有者批准而強制實施的。 同樣，以前的研究表明，通常有一個變更的審閱者將負責檢查程式碼是否符合常規。 可讀性使此過程更加明確。 在下文中，我們將重點介紹使其成為“下一代程式碼審查工具” 的CRITIQUE的功能。

審查者的建議。研究人員發現，對審稿程式碼具有先驗知識的審稿人會提供更多有用的評論，因此工具可以為審稿人選擇提供支援。我們已經看到，審閱者推薦功能受工具支援，從而優先考慮那些最近編輯/審閱受審檔案的人員。這證實了最近的研究，即頻繁的審稿人對模組的發展做出了巨大的貢獻，應與頻繁的編輯者一併納入。在Google中，實際上，找到合適的審稿人似乎沒有問題，實際上，實施推薦的模型很簡單，因為它可以以程式設計方式識別所有者。這與其他用於標識審閱者的提議的工具相反，審閱者已經審閱了具有相似名稱的檔案或考慮了諸如審閱中包含的評論數量之類的功能。 Google的工作重點是處理審稿人的工作量和暫時缺勤（與Microsoft的研究一致）。

靜態分析整合。對88位Mozilla開發人員進行的定性研究發現，靜態分析整合是程式碼審查最常用的功能。 自動進行的分析使審閱者可以專注於更改的可理解性和可維護性，而不會因為瑣碎的評論（例如關於格式）而分心。 我們在Google的調查向我們展示了在程式碼審閱工具中進行靜態分析整合的實際含義。CRITIQUE為分析作者集成了反饋渠道：審閱者可以選擇在分析生成的評論上單擊“請修復”，以表示作者應修復該問題，作者或審稿人都可以單擊“無用”以標記對審閱過程無用的分析結果。具有較高“無用”點選率的分析儀已固定或禁用。我們發現，這種反饋迴圈對於維持開發人員對分析結果的信任至關重要。

協作審查之外的審查工具。最後，我們找到了有力的證據，表明CRITIQUE的使用超出了審查程式碼。 變更作者使用CRITIQUE來檢查差異並瀏覽分析工具的結果。 在某些情況下，程式碼審查是變更開發過程的一部分：一個審查者可能會發送未完成的變更，以便決定如何完成實施。此外，開發人員還使用CRITIQUE來檢查提交的更改的歷史，只要這些更改被批准即可。 這與Sutherland和Venolia設想的將程式碼審查資料用於開發的有益用法相一致。 將來的工作可以調查程式碼審查工具的這些意外的和潛在的有影響的非審查使用。

在Google，知識轉移是程式碼審查教育動機的一部分。 我們試圖透過檢視評論和編輯/審閱的檔案來量化此效果。 隨著開發人員積累了在Google工作的經驗，他們對其更改發表的評論平均減少了（圖2）。在過去一年內開始工作的Google開發人員，每次更改的註釋通常多於兩倍。先前的工作發現，作者認為來自審閱者的註釋無用，而無用註釋的數目則隨著經驗的增加而減少。 我們假設評論的減少是由於審閱者在使用程式碼庫建立譜系關係時需要詢問較少的問題的結果，並佐證了程式碼審閱的教育方面可能隨著時間的流逝而得到回報的假說。此外，我們可以看到， 由Google的工程師編輯和審查的檔案，以及這兩個集合的結合，隨著資歷的增加而增加（圖3），並且看到的檔案總數明顯大於編輯的檔案數。 在公司工作（以3個月為增量），然後計算他們已編輯和審閱的檔案數。在以後的工作中，更好地瞭解審閱檔案如何影響開發人員的流利性將是很有意思的。

圖3. 全職員工隨時間檢視（編輯或審閱，或兩者都有）的不同檔案的數量。

8.結論

我們的研究發現，程式碼審查是Google開發工作流程的重要方面。擔任所有職務的開發人員都將其視為提供多種好處的環境，並且在此上下文中，開發人員可以相互學習程式碼庫，維護團隊程式碼庫的完整性以及搭建，建立和發展確保程式碼庫可讀性和一致性的規範。開發人員報告說，他們對審查程式碼的要求感到滿意。大部分更改很小，只有一名審閱者，除了提交授權外沒有其他評論。在一週中，有70％的更改在郵寄出去進行初審後不到24小時內就會提交。這些特徵使程式碼審查比其他採用類似過程的專案更輕便。此外，我們發現Google在其實踐中包含了一些研究思想，從而使當前研究趨勢的實踐意義顯而易見。

原文地址:https://dl.acm.org/doi/10.1145/3183519.3183525