Google 是如何做 Code Review 的

2019 年 11 月 12 日
筆記

作者 | Michaela Greiler

翻譯 | 漫慢忙

本文翻譯自 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有一些公司層級的要求，程式碼審查者必須達到這些要求才能批准程式碼更改。這與 Google 強大的程式碼所有權有關。程式碼庫的每個目錄均由一組人員明確擁有。為了能夠批准程式碼更改，至少一名審閱者必須是受審程式碼的所有者。這個人充當守門員的角色。僅當此人同意時，才能簽入程式碼。

另一個嚴格的要求是，至少一個審查人員必須接受程式碼「可讀性」的培訓。這意味著該人必須已獲得可讀性認證。該認證表明他們已經證明自己知道程式碼的可讀性和可維護性。

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

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

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

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

在另一方面，同樣重要的是足夠多的人有這樣的可讀性認證。否則，這會造成審核的瓶頸。眾所周知，等待程式碼審查回饋是程式碼審查期間的主要陷阱之一。儘管要花很多精力來獲得可讀性證書，但顯然比更改等級或資歷更容易。

如何獲得可讀性認證

為了展示其對程式碼進行可讀性審查的能力，Google 的開發人員進行了「對其程式碼審查實踐的審查」。因此，開發人員將程式碼更改提交給可讀性專家團隊。這些人將檢查程式碼。但是這種檢查並不像普通的程式碼審查那樣。可讀性專家會仔細檢查程式碼。此類審查的目的是指出每個小錯誤以及每個改進的潛力，尤其是在編碼約定和編碼樣式方面。而且，諸如縮進或多餘空間之類的挑剔問題也是此過程的一部分。如果您有興趣，可以在這裡1找到 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