Google 是如何作 Code Review 的

本文由知乎網友 漫慢忙 翻譯自 Dr. Michaela Greiler 的 Code Reviews at Google are lightweight and fast，做者所在的團隊調研了 Google 是如何作代碼審查的，並作了相關的總結。原文附有大量連接資源，在此沒有整理出來，相關連接能夠查看原文獲取。

Google 的代碼審查在工程實踐中起着重要做用，而且 Google 早期就已經開始採用。直到今天，代碼審查仍用於保證代碼庫的整潔，一致，並確保沒有人隨意提交代碼。Google 代碼審查過程看上去與 Microsoft 的代碼審查類似，不過仍有一些差異，讓代碼審查過程變得很輕。

本文展現了 Google 的代碼審查的流程以及與 Microsoft 的代碼審查的不一樣之處。尤爲是展現了 Google 的 25,000 名工程師爲什麼能比同等規模的其餘公司更快地實施代碼審查。

Google 的代碼審查研究

Google 的研究員 Caitlin Sadowski 和其餘人進行了一項研究，以瞭解 Google 的內部代碼審查流程。這項研究與 Microsoft 的代碼審查研究類似，所以能夠比較兩家公司的代碼審查過程。

Google 的通用代碼審查流程

Google 的通用代碼審查與 Microsoft 的通用代碼審查很是類似。讓咱們舉一個例子，這回咱們以 Mark 爲假想員工。

準備要審查的代碼

這一切都是在 Mark 對代碼進行了一些更改並但願將這些代碼更改合併到共享代碼庫開始的。與 Microsoft 類似，Google 藉助工具來進行代碼審查。所以，在 Mark 將他的代碼更改發送出去進行審覈以前，他使用該工具最後一次瀏覽了該代碼。

Google 的內部代碼檢查工具 Critique 提供了一些對比功能，這些功能使 Mark 能夠輕鬆發現錯誤並查看新版本代碼中的更改。

在將代碼發送出去進行審覈以前，Mark 須要執行另外一個操做：經過靜態分析工具運行代碼。所以，Mark 運行了 Tricorder（一種在 Google 普遍使用的工具），並檢查了靜態分析的結果。當他對本身的更改感到滿意時，他會將更改發送給至少一位代碼審閱者。

審閱人提供反饋

代碼審閱者仔細查看代碼並在發現問題或有疑問時留下評論。而後，Mark 經過更改代碼或回覆評論來解決每一個評論。在 Mark 對所檢查的代碼進行了一些更改後，他將上載新版本供審閱者再次檢查。若是審閱者感到滿意了，她能夠經過將其標記爲 「LGTM(looks good to me)」來批准更改。爲了可以將代碼提交到共享代碼庫，至少須要一名審閱者批准該代碼。

這個代碼審查生命週期，看起來像是 Microsoft 的代碼審查的副本。可是，接下來將向您展現一些巨大的差別。

公司範圍內的審查政策

首先，Google 要求對每一個代碼更改進行審查。沒有例外。

另外一方面，在 Microsoft，代碼審查以及審查的方式和內容由部門或團隊自行決定。例如，某些團隊會跳過代碼審查中的細微變化。一般，公司範圍內沒有關於代碼審查的統一政策。團隊和部門決定須要多少代碼審閱者，或者代碼審查如何與測試和靜態分析活動等等聯繫起來。

Google 的代碼審查要求全部權和可讀性

一樣與微軟不一樣的是，谷歌有一些公司層級的要求，代碼審查者必須達到這些要求才能批准代碼更改。這與 Google 強大的代碼全部權有關。代碼庫的每一個目錄均由一組人員明確擁有。爲了可以批准代碼更改，至少一名審閱者必須是受審代碼的全部者。這我的充當守門員的角色。僅當此人贊成時，才能簽入代碼。

另外一個嚴格的要求是，至少一個審查人員必須接受代碼「可讀性」的培訓。這意味着該人必須已得到可讀性認證。該認證代表他們已經證實本身知道代碼的可讀性和可維護性。

必須得到每種語言的可讀性證實。這樣的標準是確保代碼規範和設計一致的好方法。

對審閱者的要求不僅是資歷或地位

儘管許多其餘公司（包括Microsoft的多個部門）看重審閱者的資歷、專業領域以及決策權的層次結構，但 Google 卻更看重全部權和可讀性認證。

這解決了一些常見的代碼審查陷阱。要求高級開發人員批准代碼很容易致使工做過載，進而形成瓶頸。

在另外一方面，一樣重要的是足夠多的人有這樣的可讀性認證。不然，這會形成審覈的瓶頸。衆所周知，等待代碼審查反饋是代碼審查期間的主要陷阱之一。儘管要花不少精力來得到可讀性證書，但顯然比更改等級或資歷更容易。

如何得到可讀性認證

爲了展現其對代碼進行可讀性審查的能力，Google 的開發人員進行了「對其代碼審查實踐的審查」。所以，開發人員將代碼更改提交給可讀性專家團隊。這些人將檢查代碼。可是這種檢查並不像普通的代碼審查那樣。可讀性專家會仔細檢查代碼。此類審查的目的是指出每一個小錯誤以及每一個改進的潛力，尤爲是在編碼約定和編碼樣式方面。並且，諸如縮進或多餘空間之類的挑剔問題也是此過程的一部分。若是您有興趣，能夠在這裏¹找到 Google 的各類語言的編碼規範指南。

一旦專家們確信開發人員學會了並可以應用 Google 的編碼風格和約定，他們就會頒發可讀性認證。

批准代碼須要什麼

所以，要歸納一下，要使您的代碼在 Google 上得到批准，您至少須要一名代碼審查人員對代碼擁有全部權，並擁有所用語言的可讀性認證。若是知足這兩個條件，那麼就能夠了。

此外，在 Google 團隊中，存在多個開發人員必須批准或對審閱者執行不一樣標準的地方。可是，通常規則是，一個開發人員的承認就足夠了。

Google 的代碼審查輕巧快捷

Google 明確但願其代碼審查輕巧而快速。即便 Google 強制執行全部權和可讀性標準以進行批准，但代碼審覈過程仍很是快（平均4個小時）。較小的更改將在 1 小時內就能夠獲得審查，較大的更改將在 5 小時內獲得審查。其餘公司報告的平均週轉時間超過15小時。

那麼，Google如何作到這一點？

好了，查看一下數據^[2]，咱們能夠發現有兩個重要因素：審查參與者的數量和變動規模。

只需一名審閱者能夠加快代碼審閱速度

該研究最有趣的發現之一是，超過 75％ 的代碼審查只有一名審閱者。這很不尋常。研究代表，兩位審閱人更能提供有價值的反饋。

在 Goggle 中，僅須要一名審閱者彷佛是一個有意識的決定，爲了速度而下降嚴格程度。只有這樣，Google 才能實現快速的週轉時間。跳過等待別人的須要，減小了不少複雜性。但這也損害了審查的嚴格性，該研究也提到了這一點。在質量方面的損失是多少是未知的。儘管如此，Google 彷佛仍是取得了不錯的成果。

小步快跑對高質量的代碼審查相當重要

這項研究的另外一個關鍵看法是修改的規模。您能想象 90％ 的代碼評審更改的文件少於 10 個嗎？這確實讓人映像深入，也解釋了爲何 Google 的代碼審查速度如此之快。大多數更改還僅更改了約 24 行代碼。與包括微軟在內的其餘公司的研究報告相比，這種變動的規模要小得多。

審查小的、一致的變動是一種行之有效的代碼審查最佳實踐。首先，它提升了查看速度。正如咱們在對有價值的代碼審查反饋的研究中所看到的那樣，它還提升了代碼審查反饋的價值。代碼審查反饋的有效性隨代碼審查規模的增長而下降。Google 員工深知這一點，並常常提交少許代碼更改。

代碼審查是否有價值？

在分析 Microsoft 的代碼審查實踐和工具時，我常常思考在代碼審查期間提供價值的真正含義。何時代碼評審值得讓一個團隊在上面花費時間？

爲了回答這個問題，我求助於開發人員，問他們爲何進行代碼審查以及什麼時候從中得到價值。

事實證實，代碼審查確定是能提供價值。即便某些代碼審查不會致使任何更改也能夠，但重要的是大多數代碼審查實際上會對代碼產生影響。不然，咱們能夠跳過它們，對嗎？

所以，回到 Google 的研究中，我發現有趣的是，研究人員還假設，若是不採起任何措施，則可能會跳過代碼審查。好消息是，Google 中 80％ 的代碼審查確實要求開發人員採起行動。這清楚代表代碼審查對代碼庫有積極影響。可是那剩餘的 20％ 呢？浪費時間嗎？

事情並非那麼簡單。幸運的是，代碼審查可帶來普遍的好處。

Google 進行代碼審查的動機和得到的收益

儘管代碼審查一般與發現錯誤相關，可是一些關於代碼審查的研究代表，進行代碼審查的好處和動機遠不止這些。此外，Google 員工都知道代碼審查的好處是多方面的，尤爲是遵循了代碼審查最佳實踐。在 Google 引入代碼審查的員工的最初願景是迫使開發人員編寫其餘開發人員能夠理解的代碼。

在這項研究中，Google 員工說明了進行代碼審查的如下動機：

• 教育（指導，學習，知識傳播）

• 保持規範（例如進行適當的測試，樣式和設計的一致性）

• 守護（確保安全性，提供額外的安全網，以便單個開發人員不能提交任意代碼）

• 事故預防（包括確保儘量好地防止錯誤和缺陷，並確保源代碼質量高）。

• 跟蹤和跟蹤決策（瞭解代碼的演變以及發生更改的緣由和方式）

動機因角色而異

在 Google 進行代碼審查研究的另外一個有趣發現是，進行代碼審查的動機和指望取決於關係人的角色和職責。例如，經理對在代碼庫中建立一致的編碼樣式所帶來的好處更感興趣。另外一方面，開發人員更關心發現缺陷或錯誤。

對於代碼審查的起因，Google 員工和 Microsoft 工程師的理由是一致的，除了 Microsoft 員工不會將代碼審查描述爲「守護」的方式。例如，安全檢查不是 Microsoft 常規代碼審查過程的一部分。

Google 的代碼審查工具

在 Google，藉助工具能夠完成代碼審查。Google 主要使用兩種代碼審查系統。對於開源代碼和與外部協做者共享的代碼，如 Go、Chromium、Android，Google 員工使用 Gerrit 代碼審查工具。Gerrit 是與 Git 集成的開源代碼審查工具。

另外一方面，對於內部代碼，Google 員工使用稱爲 Critique 的內部代碼審查工具。沒有關於 Critique 功能的詳細描述，可是 Google 員工彷佛對這套工做流程和功能很是滿意。

Microsoft 的許多代碼檢查也經過工具執行。可是在 Microsoft，其餘形式的代碼審查也有其公正而合理的保證。有時，沒有什麼能戰勝面對面的對話。

Google 的統一流程針對速度進行了優化

綜上所述，Google 對於代碼審查有明確的規定。您與提交共享代碼庫之間的關係是至少一個具備代碼全部權的人員和可讀性認證的審覈批准。大多數評論只有一名評論者，這也使代碼審查過程變得輕便。公司範圍內的代碼規範，使代碼清晰易讀。結合較小的代碼更改量，Google 員工能夠在 1-5 個小時內得到代碼審覈反饋。

與 Microsoft 員工相似，Google 員工對代碼審查過程很是滿意，並發現它是有價值的工程實踐。

參考

[1]https://github.com/google/styleguide [2]https://sback.it/publications/icse2018seip.pdf