現代代碼審查：Google案例研究

摘要

使用基於工具的輕量級代碼檢查代碼更改（又名現代代碼審查）已成爲普遍的規範，應用於各類開源和產業系統。在本文中，咱們對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）。

id	融合實踐
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）。例如，維護工程師與具備不一樣資歷的工程師（項目負責人，專家可讀性審閱者或「新」團隊成員）之間的規範衝突，而與同伴或其餘團隊相比則少一些，而看門人和事故預防則是主要的。具備普遍的價值，幷包含多種不一樣的關係。

圖1. 關係圖，描述了哪些評論指望主題主要出如今特定做者/評論者上下文中。

發現2.對Google進行特定代碼審查的指望取決於做者與審查者之間的工做關係。

5.結果：實踐

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

5.1 描述審查過程

Google的代碼審查與兩個概念相關：全部權和可讀性。 咱們首先介紹它們，而後描述審閱過程的流程，而後得出內部審閱工具CRITIQUE與其餘審閱工具不一樣的特色。

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

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

代碼審查流程。審查流程與評論緊密結合，其工做方式以下：

1。 建立：做者開始修改，添加或刪除某些代碼； 一旦準備好，他們就會進行更改。

2。 預覽：做者而後使用CRITIQUE來查看更改的差別，並查看自動代碼分析器的結果（例如，來自Tricorder [36]）。 準備就緒後，做者將更改發送給一個或多個審閱者。

3。 評論：審閱者能夠在Web UI中查看差別，並隨時起草評論。 程序分析結果（若是存在）也對審閱者可見。未解決的評論顯示爲變動做者必須解決的操做項目。已解決的評論包括可選或信息性評論，可能不須要變動做者採起任何行動。

4。 解決反饋：做者如今能夠經過更新更改或經過回覆評論來處理註釋。更新更改後，做者將上載新快照。 做者和審閱者能夠查看任意一對快照之間的差別，以瞭解發生了什麼變化。

5。 批准：解決全部評論後，評論者會批准該更改並將其標記爲「 LGTM」（對我來講很好 Looks Good To Me）。 要最終進行更改，開發人員一般必須至少得到一名審閱者的批准。一般，只需一名審閱者便可知足上述全部權和可讀性要求。

咱們嘗試量化「輕量級」審閱的方式（CP1）。 咱們經過檢查變動做者郵寄了一組可解決之前未解決的註釋的評論來衡量評論中來回的次數。咱們假設一個迭代對應於一個做者解決某個評論的一個實例； 零重複意味着做者能夠當即提交。咱們發現全部更改中有80％以上最多涉及解決評論的重複。

建議審閱者。要肯定最佳的人來從新審閱更改，CRITIQUE依靠一種工具來分析變動並建議可能的審閱者。 此工具肯定知足更改中全部文件的審閱要求所需的最小審閱者集。 請注意，一般只須要一名審閱者，由於更改一般是由擁有文件查詢全部權和/或可讀權的人創做的。 該工具對最近編輯和/或審閱所包含文件的審閱者進行優先級排序。 因爲還沒有創建新的團隊成員，由於他們還沒有創建審覈/編輯歷史記錄，所以已明確添加爲他們。 未分配的審閱者還能夠對更改發表評論（並可能批准）。尋找審閱者的工具支持一般僅在文件更改超出特定團隊的狀況下才須要。 在一個團隊內，開發人員知道向誰發送更改。 爲了將可能發送給團隊中任何人的更改，許多團隊使用一種系統，該系統將循環發送到團隊電子郵件地址的審閱分配給配置的團隊成員，同時考慮到審閱負載和休假。

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

發現3. Google代碼審覈過程與輕量級和靈活的融合作法保持一致。 可是，與其餘研究過的系統相比，全部權和可讀權是明確的，而且起着關鍵做用。 審閱工具包括審閱者推薦和代碼分析結果。

5.2 量化審覈流程

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

審查頻率和速度。Rigby和Bird發現快節奏的迭代開發也適用於現代代碼審查：在他們的項目中，開發人員的工做間隔很是短。 爲了找到答案，他們分析了評論的頻率和速度。

在Google，就頻率而言，咱們發現處於中位數上的開發者每週大約進行3次更改，而80％的開發者每週進行少於7次更改。 一樣，開發人員每週審覈的變動中位數爲4，而80％的審閱者每週審覈的變動少於10。 在速度方面，咱們發現開發人員必須等待對其更改的初步反饋，對於較小的更改，平均時間少於一小時，對於較大的更改，平均時間少於5小時。 整個審閱過程的整體（全部代碼大小）中值延遲小於4小時。 這比Rigby和Bird [33]報告的平均批准時間要低得多，AMD的批准時間中位數爲17.5小時，Chrome OS爲15.7小時，三個Microsoft項目爲14.七、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。

	bad				good
對於此更改，審覈過程很好地利用了個人時間	2	4	14	11	13
總的來講，我認爲Google的代碼審查頗有價值	0	0	0	14	30
對於此更改，反饋量爲	2	2	34	5	0

表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設想的將代碼審查數據用於開發的有益用法相一致。 未來的工做能夠調查代碼審查工具的這些意外的和潛在的有影響的非審查使用。

7.3 知識傳播

知識轉移是Rigby和Bird提出的主題。 爲了衡量因爲代碼審查而致使的知識轉移，他們從先驗工做的角度出發，經過測量變動，審查和兩個集合的不一樣文件數來衡量專業知識，以更改的文件數爲依據 。他們發現開發人員經過代碼審查瞭解更多文件。

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

圖2. 審查者的評論和開發者在Google的任職年限

圖3. 全職員工隨時間查看（編輯或審閱，或二者都有）的不一樣文件的數量。

8.結論

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

原文地址：https://dl.acm.org/doi/10.114...