Modern Code Review翻译

原文
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小时每周来说是比较低的。

再说一遍，如果觉得看了之后没什么卵用，请别骂我，骂作者去。我个人也觉得干货不多