《谷歌的软件工程》之Critique: 谷歌的Code-Review工具

《Software Engineering at Google》 原文： Software Engineering at Google (abseil.io)

章节：Critique: Google’s Code Review Tool 

谷歌的Critique工具在他们公司内部很受欢迎，开发者满意度高达 97%。虽然Critique没有开源，我们总结它的优秀经验，结合公司的研发特点，可以基于开源的Gerrit定制开发优秀的Code-Review工具。

1. Code-Review工具的设计原则

（1）简洁性

Critique的用户界面（UI）的设计理念是使代码审查变得简单易行，避免了许多不必要的选择，并且界面流畅。UI加载速度快，导航简便并支持热键操作，而且对于更改是否已审查的总体状态有清晰的视觉标记。

（2）信任的基础

代码审查不是为了拖慢别人的步伐；相反，它是为了赋予他人能力。尽可能地信任同事是使其工作的关键。例如，这可能意味着信任代码作者的修改，而不需要一个额外的审查阶段来二次检查那些小的评论是否真的被解决了。通过使更改公开可访问（供查看和审查），在整个谷歌范围内，信任也得以体现。

（3）通用沟通

沟通问题很少通过工具解决。Critique优先考虑用户对代码变更进行评论的通用方式，而不是复杂的协议。Critique鼓励用户在他们的评论中明确表达他们想要什么，甚至建议一些编辑，而不是使数据模型和过程更加复杂。即使有了最好的代码审查工具， 沟通也可能出错，因为用户是人类。

（4）工作流程集成

Critique与其他核心软件开发工具有许多集成点。开发人员可以通过代码搜索和浏览工具轻松地导航查看正在审查的代码，使用我们的基于Web的代码编辑工具编辑代码，或查看与代码变更相关联的测试结果。

2. Code-Review流程

流程分为6步，但谷歌的流程是比较灵活的，比如代码评审人可以取消自己对代码的评审任务或者安排更适合的其他人评审，开发人员可以推迟评审。甚至紧急情况下，开发人员可以强制合入代码，合入之后再做Code-Review.

2.1 提交代码修改

在个人workspace修改代码，提交修改到Critique。

Critique对Diff算法做了好些增强：语法高亮显示，交叉引用（代码搜索），字符级别的行内差异，可选择忽略空白，可标记代码移动（不像简单的diff算法只能标记为删除和添加）。

提交会自动出发代码静态分析，分析结果展示在Diff页面，有些告警会提供fix建议，开发人员一键查看fix，没问题的话一键应用，提高fix代码问题的效率。

Critique集成了很多工具：Cider云IDE，CodeSearch代码搜索，Tricorder展示代码静态分析结果，Rapid打包和部署二进制，Zapfhahn测试覆盖率计算工具。

2.2 申请代码评审

开发人员对代码修改得比较满意后就可以发邮件给评审人，Critique提供合适的评审人，主要考虑这几个方面：（1）谁是被修改代码的负责人，（2）谁对这部分代码最熟悉，（3）谁的时间比较方便。

发出代码评审请求会出发"presubmits"，比如跑自动化测试。自动化测试需要测试样机等资源，所以不能像代码静态分析一样每一个patch都自动执行。自动化测试如果失败，Critique会拦截代码评审。

2.3 评审代码和修改代码回复评审

每个人都能自由地评审代码。Critique可以跟踪个人评审过程。评审人看到代码分析的结果 ，如果觉得有些问题是需要修复的，就可以点“请修改”按钮自动创建一个未解决的评审意见，需要开发人员修改。评审人也可以提供修改意见。

Critique提供了很多机制，可以明确评论和迭代进行到什么位置了。如果涉及有多位评审人，可以管理评审顺序，一位评审完轮到下一位。Critique有仪表板可以查看相关的所有修改和状态。

评审代码和修改代码后再评审，可能会重复多次。

2.4 代码评审通过

Critique的打分分为三部分：LGTM("looks good to me")，同意，未解决的评审意见。Gerrit是通过+2和-2表示同意提交或不同意提交。

2.5 代码合入

代码评审通过后，Critique一键合入代码，如果代码静态分析和presubmits都没有未解决问题了，代码就合入到代码仓里了。

代码合入后，还可以通过Critique评审代码，也可以回退修改。

3. 总结

Code-Review要平衡投入产出比，不断优化评审的效率。Critique可以定制代码静态分析的检查项和presubmits。

信任和交流是代码评审的流程的核心，工具可以固化一些经验，但不能取代它们。Critique的成功是因为集成了很多有用的工具。