受谷歌启发的 13 条代码审查标准

在本文中，我们将简要介绍13条代码审查标准，它们能极大地助力提升软件的健康状况，同时让开发人员工作得更舒心。

顾名思义，代码审查是一个过程，在此过程中，一名或多名开发人员对另一名开发人员（代码作者）所编写的代码进行审查或筛查，以确保：

• 代码没有任何错误，不存在漏洞或问题；
• 代码符合所有的质量及样式指南要求与标准；
• 代码能实现其预期功能；
• 代码合并后，会使代码库的整体状况变得更好。

这就是代码审查成为软件开发关键环节的原因所在。代码审查人员扮演着把关者的角色，决定着代码是否达到可纳入代码库并进入生产环境的状态。

谷歌以其卓越的技术闻名，他们有着行之有效的代码审查标准，这些标准似乎凸显了在审查代码时需要牢记的一些要点。在谷歌，“代码审查的主要目的是确保谷歌代码库的整体代码健康状况能随着时间不断改善。”——谷歌工程实践文档

以下是在审查变更列表（拉取请求）时需要牢记的一些事项。

代码审查标准

1、代码应提升系统整体健康状况

每个变更列表（拉取请求）都要能提升系统的整体健康状况。其理念在于，通过这类细微的改进，软件或代码库的健康状况在每次合并后都能得到改善。

2、快速进行代码审查、回复及反馈

首先也是最重要的一点，不要拖延推送（合并）更优质的代码。别期望代码是完美无缺的。如果代码所处的状态能够提升系统的整体健康状况，那就可以发布它了。

“这里的关键在于，根本不存在‘完美’的代码——只有更好的代码。”——谷歌工程实践文档

如果你当时没有在专注处理某项任务，那么在变更列表（拉取请求）到来后应尽快进行代码审查；不过，回复一个拉取请求（变更列表）最长不应超过一个工作日。预计一个变更列表（拉取请求）在一天内会经历多轮部分或完整的代码审查。

3、在代码审查过程中开展教育并启发他人

在代码审查期间，尽可能通过分享知识和经验来提供指导。

4、审查代码时遵循相关标准

始终牢记，样式指南、编码标准等文档在代码审查过程中具有绝对权威性。例如，要强制统一制表符与空格的使用方式，你可以参考编码规范。

如果Java是你选用的编程语言，那么你可能会觉得下面这篇总结大型科技公司Java编码最佳实践的文章很有用：《Java编码最佳实践简述》

5、解决代码审查冲突

依据样式指南和编码标准文档中约定好的最佳实践来解决冲突，同时向在产品相关领域更具知识和经验的人员寻求建议。

根据冲突的严重程度采取不同的处理方式。如果你的审查意见是可选的或属于次要问题，那么在审查意见中注明这一点，然后让代码作者自行决定是否处理这些意见。

作为代码审查人员，在缺乏样式指南或编码标准的情况下，你至少可以建议变更列表（拉取请求）要与代码库的其余部分保持一致。

6、将用户界面（UI）变更演示作为代码审查的一部分

如果变更列表（拉取请求）涉及用户界面的更改，那么除了进行代码审查外，还需要进行演示，以确保视觉效果符合预期且与设计原型相匹配。

对于前端的变更列表（拉取请求），始终建议进行演示或走查，或者确保变更列表中包含必要的用户界面自动化测试，用于验证所添加或更新的功能。

7、确保代码审查伴随相应测试

除非是紧急情况，否则拉取请求（变更列表）应附带所有必要的测试，即单元测试、集成测试、端到端测试等。

紧急情况可能是需要尽快修复的漏洞或安全缺陷，这种情况下可以稍后再添加测试。在类似这样的情形中，要确保创建相应的任务单/问题记录，并安排专人在热修复或部署完成后负责正确地添加测试。

没有足够充分的理由可以跳过测试。如果由于时间限制，部分目标面临无法达成的风险，那么解决方案不应是跳过测试，而是缩小交付范围。

8、专注时不要中断手头工作去做代码审查

如果你正在专注处理一项任务，不要中断自己，因为重新回到正轨可能需要花费很长时间。换句话说，中断一位专注的开发人员所付出的代价，要高于让一位开发人员等待代码审查的代价。可以在计划的休息时间（比如午餐、喝咖啡等时间）之后再进行代码审查。

并不总是期望在同一天内完成整个代码审查流程并进行合并。重要的是要尽快给代码作者一些反馈。例如，你可能没办法进行完整的审查，但可以快速指出一些有待查看的问题。这将极大地有助于减少代码审查过程中的挫败感。

9、全面审查，切勿臆测

查看分配给你审查的每一行代码。不要对人工编写的类和方法做任何臆测，要确保自己理解代码正在做什么。

务必理解你正在审查的代码。如果不理解，那就弄清楚或者请求进行代码走查/解释。如果有部分代码你没有资格审查，那么要确保有其他具备相应资格的开发人员来审查这些代码部分。

10、带着宏观视角审查代码

从更广泛的背景下来审视变更往往很有帮助。例如，一个文件被修改了，新增了四行代码。不要只审查这四行代码，而是要考虑审查整个文件，并查看新增内容。它们是否会降低现有代码的质量，或者是否会使现有函数有必要进行重构呢？

如果这类简单的新增内容不在函数/方法或类的背景下进行审查，那么随着时间的推移，你将会接手一个难以维护、极度混乱、不易测试、功能繁杂且难以扩展或重构的类。

记住，正如随着时间的推移，细微的改进会累积起来，最终打造出一个缺陷极少的优秀产品一样，同样地，随着时间的推移，轻微的代码质量下降或技术债务也会累积，最终导致产品难以维护和扩展。

11、在代码审查过程中认可并鼓励优秀工作成果

如果你在变更列表中发现了优秀之处，不要忘了向作者表示称赞并给予鼓励。这是我个人以前未曾做到的一点。代码审查的目的不应仅仅是查找错误，还应是鼓励和指导开发人员所做的出色工作。

12、在代码审查时做到用心、尊重、友善且表意清晰

在代码审查期间，做到友善、表意清晰、有礼貌且尊重他人，同时向作者提供清晰且有帮助的审查意见，这一点至关重要。审查代码时，要确保审查意见是针对代码本身，而非针对开发人员。

以下是谷歌提供的一份关于如何在代码审查中做到尊重他人的指南：《尊重式代码审查：给代码审查人员的指南》。

13、解释你的代码审查意见并留意范围

每当代码审查意见建议采用另一种方法或者指出某个问题时，关键是要依据自己的知识和经验解释原因并提供示例，以帮助开发人员理解你的建议将如何有助于提升代码质量。

在建议修复或更改时，要在如何引导作者修复代码方面找到恰当的平衡。例如，我很欣赏给予指导、解释以及一些提示或建议，但并非直接给出整个解决方案。

写在最后

感谢阅读，希望你喜欢这篇文章。如果你有任何意见或建议，请随时在评论区与我们分享。

请持续关注后续关于类似主题的文章。