Google的程式碼評審在工程實踐中發揮著重要作用，並且早在谷歌就已經採用。直到今天，它們仍然用於保持程式碼庫的清潔，連貫並確保不提交任意程式碼。儘管程式碼評審過程與Microsoft的程式碼評審類似，但有一些Google細節允許特定的輕量級程式碼評審過程。

因此，讓我向您展示Google的程式碼評審是什麼樣的，以及它們與Microsoft的程式碼評審區別開來的原因。特別是，我將向您展示什麼允許Google的25,000名工程師比其他這樣規模的公司更快地評審他們的程式碼。那麼，讓我們開始吧。

Google的程式碼評審研究

谷歌研究員凱特琳·薩多夫斯基（Caitlin Sadowski）和其他人已經開展了一項研究，以瞭解谷歌的內部程式碼審查流程。這項研究類似於微軟的程式碼審查研究，這使得比較兩家公司的程式碼審查流程變得有趣。

Google的典型程式碼稽核看起來非常像Microsoft的典型程式碼稽核。讓我們通過想象一下Google員工的程式碼稽核流程來看一個例子。我們叫他馬克Mark。

1. 準備程式碼以供評審

這一切都是在馬克對程式碼進行一些更改並希望將這些程式碼更改與共享程式碼庫合併之後開始的。在Google，程式碼審查與Microsoft類似，在工具的幫助下完成。因此，在Mark傳送他的程式碼更改以供審閱之前，他使用該工具最後一次檢視程式碼。

谷歌的內部程式碼審查工具Critique提供了一些差異化功能，使Mark能夠輕鬆發現錯誤並檢視新版本程式碼中的變化。

在傳送程式碼進行稽核之前，Mark需要執行另一個步驟。通過靜態分析工具執行程式碼，例如，在Google廣泛使用的工具Tricorder，並審查靜態分析工具的結果。當他對自己的變化感到滿意時，他會將更改傳送給至少一位程式碼稽核人員。

2. 評審者提供反饋

程式碼評審員仔細檢視程式碼，如果她發現問題或需要澄清，則留下評論。Mark然後通過更改程式碼或回覆評論來處理每個評論。如果Mark對正在稽核的程式碼進行了一些更改，他會上傳新版本供審閱者再次檢查。如果評審者滿意，她可以通過將其標記為“LGTM”來批准更改（對我來說看起來不錯）。為了能夠將程式碼提交到共享程式碼庫，至少一個評審者必須批准程式碼。

從遠處看這段程式碼審查生命週期，它看起來像是Microsoft的程式碼審查的副本。但是，我現在會向你們展示一些深刻的分歧。

3. 公司範圍的批准政策

首先，Google要求對每個程式碼更改進行稽核。沒有例外。

另一方面，在Microsoft，程式碼審查以及需要審查的方式和內容由各部門或團隊自行決定。例如，一些團隊跳過程式碼審查，以進行小規模和微不足道的更改。一般而言，程式碼審查沒有任何公司範圍的政策。團隊和部門決定需要多少程式碼審查員，或者程式碼審查如何與測試和靜態分析活動等相關聯。

4. Google特有的所有權和可讀性的程式碼稽核

與微軟相反，谷歌還有一些公司範圍的要求，程式碼審查員必須滿足這些要求才能批准程式碼更改。一個與谷歌強大的程式碼所有權有關。程式碼庫的每個目錄都由一組人明確擁有。為了能夠獲得批准的程式碼更改，至少有一位審閱者必須是所審查程式碼的所有者。那個人充當守門人。只有當這個人給他或她好的時候，才能簽入上傳程式碼。

另一個嚴格的要求是，評審中至少有一個人必須接受程式碼“可讀性”的培訓。這意味著此人必須已獲得可讀性認證。此認證表明他們已經證明他們知道程式碼的可讀性和可維護性。 必須按語言獲得可讀性認證。擁有這樣的標準是確保風格和設計一致性的一種很好的做法。

5. 評審人的要求不是關注資歷或地位

雖然許多其他公司，包括微軟的幾個部門，而不是審視審查人員的資歷，專業領域或授予決策權的等級，但Google會考慮所有權和可讀性認證。

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

另一方面，足夠的人擁有這樣的可讀性證書也很重要。否則，它也會產生評論瓶頸。眾所周知，等待程式碼審查反饋是程式碼審查過程中的主要缺陷之一。但是，雖然獲得可讀性認證需要相當多的努力，但它比更改層次結構或資歷更容易。

6. 如何獲得可讀性認證

為了展示他們稽核程式碼的可讀性，Google的開發人員將對其“程式碼稽核實踐進行稽核 ”進行稽核。因此，開發人員將程式碼更改提交給可讀性專家團隊。那些人會檢查程式碼。但這次檢查不像普通的程式碼審查。

可讀性專家會仔細研究這些程式碼。這種評論的目的是指出每一個小錯誤和每一個改進的潛力，特別是在編碼慣例和編碼風格方面。此外，諸如縮排或額外空格之類的挑剔問題也是學習過程的一部分。有興趣的話，您可以在這裡找到各種語言的Google風格指南。

一旦專家確信開發人員已經學會並且能夠應用Google的編碼風格和慣例，他們就會頒發可讀性認證。

7.如何獲得程式碼批准

因此，回顧一下，要讓您的程式碼在Google上獲得批准，您需要至少一個程式碼稽核人員擁有程式碼所有權以及所使用語言的正確可讀性認證。如果滿足這兩個標準，那麼你很高興。

沒有例外的規則。此外，在Google團隊中，有多個開發人員必須批准，或者執行不同的審閱者標準。但是，一般規則是開發人員的批准就足夠了。

Google的程式碼評審重量輕，速度快

谷歌明確希望其程式碼審查實踐輕量且快速。即使Google強制執行所有權和可讀性標準以進行審批，程式碼稽核流程 - 平均需要4個小時 - 非常快。小的變化在1小時內審查，較大的變化在5小時內審查。其他公司報告的平均週轉時間超過15小時。

那麼，谷歌是如何做到的呢？

那麼，看看報告的資料，我們可以看到有兩個重要因素：稽核參與者的數量和變化規模。

1. 只需要一位評審員就可以加快程式碼稽核時間

該研究最有趣的發現之一是超過75％的程式碼評論只有一個評審者。這很不尋常。特別是因為研究表明兩位評審者傾向於提供更有價值的反饋。

要求只有一位評審員似乎是Goggle的一個有意識的決定，並且對速度進行嚴格的評審。只有這樣，谷歌才能實現快速週轉時間。跳過等待另一個人的需要降低了很多複雜性。但它也嚴重損害了評審的嚴謹性，研究也提到了這一點。這種質量成本是多少未知。儘管如此，谷歌似乎在這種設定方面取得了很好的成果。

2. 小的更改大小對於快速和高質量的程式碼審查至關重要

這項研究的另一個重要見解是變化的規模。你能想象，90％的程式碼評論改變了少於10個檔案？這真是令人印象深刻，也解釋了為什麼谷歌的程式碼審查是閃電般快速的。大多數更改也只有大約24行程式碼更改。這比其他公司（包括微軟）的研究報告的變化幅度要小得多。

審查小而連貫的更改是經過驗證的程式碼審查最佳實踐。首先，它提高了稽核速度。但是，正如我們在有價值的程式碼審查反饋研究中所看到的那樣，它也提高了程式碼審查反饋的價值。隨著程式碼審查的大小增加，程式碼審查反饋的有用性降低。Google員工知道這一點，並經常提交小程式碼更改。多麼聰明！

谷歌的程式碼評論速度快，主要有兩個原因。首先，Google上90％的程式碼稽核包含的檔案少於10個。其次，75％的評論只有一位評論者

谷歌的程式碼審查工具

在谷歌，程式碼審查是在工具的幫助下完成的。兩個主要的程式碼審查系統在Google上占主導地位。對於與Go，Chromium等外部協作者共享的開原始碼和程式碼，Android Google員工使用Gerrit程式碼稽核工具。Gerrit是一個與Git整合的開原始碼審查工具。

另一方面，對於內部程式碼，Google員工使用名為Critique的內部程式碼審查工具。

Microsoft的許多程式碼審查也通過工具進行。但在微軟，其他形式的程式碼審查，例如並肩審查，都有其公平合理的保證。有時，沒有什麼可以打敗面對面的談話。

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

總而言之，Google已明確指出如何批准程式碼稽核。您與共享程式碼庫的提交之間的區別在於至少一個擁有程式碼所有權和可讀性認證的人的稽核批准。大多數評論只有一個評論者在程式碼審查過程中也需要很多複雜性。公司範圍內的程式碼樣式，清晰明瞭可讀程式碼的外觀。結合較小的程式碼更改大小，Google員工可以在1-5小時內獲得程式碼稽核反饋。

與Microsofties類似，Google員工對程式碼審查流程非常滿意，並認為它是一種有價值的工程實踐。