原文
Modern Code Review: A Case Study at Google
如果覺得看了之後沒什麼卵用，請別罵我，罵作者去。我個人也覺得乾貨不多
只翻譯比較有用的第四、五、六章，另外幾章看標題就知道寫了啥。省略了一些冗餘陳述。
1 介紹
2 背景和相關工作
3 研究方法
7 討論
8 結論
4 研究結果：動機
我們試圖理解開發人員在Google進行code review時的動機和期望，首先調查了code review是如何引入的
4.1 如何開始的
Google的code review最早是由第一批員工之一引入的，我們稱他爲E。E說，引入code review的主要原因是強制開發人員編寫其他人能夠理解的代碼，他認爲這非常重要，因爲代碼必須爲後面的開發人員提供指導。在Google引入code review標誌着Google的代碼從研究爲主，轉變爲生產爲主。code review也能夠確保每一段代碼都有不止一個人熟悉，從而增加知識留在公司內部的機率。雖然審覈人員發現代碼中的bug是好現象，但在Google引入code review的首要原因是提高代碼的可理解性和可維護性。除了指導意義外，開發人員們很快發現了code review的另外三個好處：
1.檢查風格和設計的一致性；
2.確保充分的測試；
3.通過確保沒人可以隨意提交未經審覈的代碼來提高安全性。
4.2 當前的期望
通過整理我們對Google的採訪，我們發現四個Google開發人員對code review的主要期望：1.指導意義；2.規範化；3.gatekeeping；4.防止意外。
指導意義關注的是在code review中教和學，並且這和引入code review的初衷是一致的；
規範化是指面臨選擇時有一定的偏好，比如代碼的格式和API的使用模式；
gatekeeping關注的是建立和維護代碼、設計和其他工作的邊界；
意外當然是指bug、缺陷、或其他質量相關問題
除了上述這些，code review也被用於追溯歷史變更，它提供了瀏覽代碼變化歷史的能力，包括code review的批註是如何產生的、代碼是如何演變的，以及bug是如何引入的。
另外我們發現，上述4個主題的重要性取決於作者與審覈人員之間的關係。比如規範化這一條主要在不同資歷的開發人員之間審覈時體現，而在和資歷相近或者不同部門之間審覈時，主要能體現gatekeeping和防止意外這兩個主題，而指導意義體現得較爲普遍，也比較受重視。
5 研究結果：實踐
本章描述code review過程，並和之前的工作做了一些對比
5.1 描述過程
Google的code review和兩個概念相關：ownership和可讀性，我們先描述這兩個概念，然後我們再描述review流程，總結Google內部review工具Critique的特點。
Ownership，Google的代碼庫是樹形結構的，每個目錄都有明確的人員負責。雖然每個人都可以對代碼庫的每個部分進行修改，但是這些修改都要經過目錄的負責人審覈後才能提交，目錄的負責人也最好（expected to）在提交前找人review代碼。
可讀性，Google很早就定義了可讀性的概念，以保證代碼風格的一致性和代碼庫的規範。開發人員可以將修改發送給一些可讀性認證審覈人員，如果審覈人員認爲該開發人員已經理解了該語言的代碼風格和最佳實踐，開發人員就可以獲得該語言的可讀性認證。所有的修改都必須由獲得可讀性認證的人員來編寫和review。
review流程和Critique密切相關。
1.創建：開發人員修改、添加、刪除代碼
2.預覽：開發人員通過Critique查看修改的代碼和代碼分析的結果，然後開發人員將改動通過郵件發送給審覈人員
3.批註：審覈人員通過web UI查看代碼變更，並草擬批註，未完成的批註會給開發人員指示代碼的具體的位置，已完成的批註會指示一些信息
4.Addressing Feedback（不知道怎麼翻）：現在開發人員可以通過更新或回覆批註來addresses comments，當有變更發生，開發人員和審覈人員都可以看到
5.審覈：當所有批註都完成時，審覈人員給變更標記上（Looks Good To Me），爲了提交變更，開發人員至少需要獲取一位審覈人員的通過標記
我們嘗試量化什麼是“輕量”，我們通過開發人員給審覈人員發審覈郵件的次數，來衡量一次review中有多少次反覆（back-and-forth），我們假定一次迭代反映出開發人員解決了一些批註，0次迭代說明開發人員可以馬上提交了。我們發現超過80%的變更最多隻包含一次迭代。
Critique依賴一個分析變更和審覈人員推薦的工具來找出最合適的審覈人員，該工具會選定滿足審覈要求的最小審覈人員集合，通常審覈人員只有一個，一般優先挑選最近審覈或者編輯過相關代碼的人員。新成員也會被優先挑選，因爲他們還沒建立 審覈/編輯 歷史（沒看出因果關係在哪裏）。未被工具指派的審覈人員也可能會添加批註或者通過審覈。通常跨小組的代碼變會更需要工具的支持，在一個小組內，開發人員知道應該把郵件發給誰，有些小組還通過輪詢（round-robin manner）指定審覈人員，並考慮到審覈負重和假期等因素。
Critique可以顯示代碼分析的結果，分析人員或審覈人員可以給代碼提供建議的修改方式。爲了審覈變更，代碼提交前有一個pre-commit鉤子，來提供一些基本的檢查，比如基礎風格檢查、跑自動測試等。在code review工具中可以查看pre-commit鉤子的執行結果。這些檢查可以配置，小組可以強制一些項目執行檢查並自動添加郵件提醒來提高意識和透明度。
除了pre-commit的結果，Critique還通過Tricorder展示一些自動代碼分析的結果，包含簡單的風格檢查，較爲複雜的基於編譯的分析和一些項目配置的檢查。當前，Tricorder包含110個分析器，其中5個是數百個額外檢查的插件系統，Tricorder總共分析超過30種語言。
5.2 量化review過程
review頻率和速度，Rigby和Bird（全文中都有提到的名字）發現快節奏、迭代式的開發也適用於現代的code review。
在Google，開發人員平均每週有3個變更，80%的開發人員一週有7個以內的變更；平均每週review的變更是4個，80%的審覈人員每週審覈10個以內的變更。
開發人員平均在一小時以內收到他們提交的變更的反饋，對於比較大的變更，需要5小時。所有review的過程平均耗時4小時以內，這個值遠低於Rigby和Bird所報告的平均時間，17.5 hours for AMD，15.7 hours for Chrome OS，14.7, 19.8, and 18.9 hours for the three Microsoft projects，其他研究發現Microsoft平均耗時24小時。
Rigby和Bird認爲變更足夠小，review時間才能足夠少，在Google，超過35%的變更只有一個文件的改動，約90%的變更的改動文件數少於10個。超過10%的變動只改了一行代碼，平均修改代碼的行數爲24。Google的平均修改數量遠低於其他公司，AMD (44 lines), Lucent (263 lines), and Bing, Office and SQL Server at Microsoft (somewhere between those boundaries)。
審覈人員的數量一致都有爭議，Rigby和Bird的調查提出這個數量爲2比較合適，無論審覈人員是否被邀請，或者改動公開接收審覈。在Google，少於25%的變更有一個以上的審覈人員，超過99%的變更最多有5位審覈人員，平均數量是1。即便是很大的改動平均也只有2個審覈人員。
Rigby和Bird也發現，當多於2個審覈人員參與審覈時，批註的增量最少。在Google，情況有所不同，更多的審覈人員會導致更多的批註，並且批註的數量隨着修改行數的增加而增加，最高達到每個改動有12.5個批註（總共1250行變更）。大於這個數量的變更通常包含着自動生成的代碼或者大量的刪除，這會導致更多的批註。
6 研究結果：開發人員的感受
6.1 Code revirew的阻礙（breakdowns）
我們在這裏主要集中探討特定的review中遇到的問題，比如延遲和分歧。我們的研究中遇到了5個主題，其中前四個涉及過程中的阻礙。
距離：地理（開發人員和審覈人員的物理距離）和組織（不同小組和角色），這些距離被視爲審覈過程中的延遲和誤解的原因之一
社會活動：語調（tone）和力量（power）可能導致code review中的問題，tone是指有時開發人員對於review批註比較敏感，對於批註的情感分析證明，帶負面語調的批註更可能無用。power是指通過code review過程來影響他人的行爲，比如，拖延review過程和拒不審覈。
review主題：指對於某些任務，code review未必是最合適的審覈方式，比如設計工作。這導致了不匹配的預期（比如有些小組希望設計在第一次審覈前完成，另一些希望在審覈過程中討論設計）
上下文：不理解變更是如何產生的可能會導致誤解，比如，緊急修復產品問題或者可有可無的改善。
自定義：有些小組對於code review有不同的要求，比如，關注需要多少審覈人員成本。這是技術上的阻礙，因爲任意的自定義不一定總是在Critique中支持，並且可能引起誤解。
6.2 滿意度和時間成本
我們發現code review在Google內是被廣泛視爲有價值和有效率的，在內部的調查中，對Critique的滿意度爲97%。
在具體的場景下，存在不同的意見，最低的滿意度出現在很小的改動場景中，一兩行的改動，還有的是達成某種目標的變動，比如觸發某一過程的代碼。
但是大部分參與者都認爲對於他們的變更的反饋是合理的。8個參與者說批註無用，其中3個人提供了具體細節，說變更很小，code review的用處不大。只有2個參與者說在批註中發現了bug。
我們還調查了開發人員在review代碼中花費的時間。我們總結了2016年10月開始的5個星期內所有review階段花費的時間，並計算了每個用戶每週的平均值，過濾掉沒有數據的用戶，我們發現開發人員平均花費3.2（平均每週2.6小時）小時來review變更，相對OSS工程的6.4小時每週來說是比較低的。
再說一遍，如果覺得看了之後沒什麼卵用，請別罵我，罵作者去。我個人也覺得乾貨不多