做不好Code Review的6大原因

Code reviews如果实施不当，它可能会严重拖慢团队的交付能力——许多代码更改会在Code reviews活动中停留几天（甚至几周），最终影响产品的上市时间。为何你的Code reviews可能会耗时长久，常见原因如下：

• 缺乏编程指南
• 没有使用自动化检查
• 没有做自我审查
• 提交了庞大的PR
• 提交了内容模糊的PR
• 没有为完成评审设定时间期限

1. 缺乏编程指南

每个团队都应该有一套人人同意的编程指南。这套编程指南应该包含命名规范、文件夹结构、代码格式以及单元测试、验证等活动的最佳实践。

如果没有明确的指导方针和约定规范，每个开发人员就会按照自己喜欢的方式去编写代码，这将导致在code review期间出现大量争论和分歧。如果你注意到有许多关于代码格式、命名规范等方面的评论意见，那么你就需要开始组织团队开展关于编程指南的讨论了。

你的团队既可以制定自己的指南，也能借鉴其他公司的智慧，比如参考谷歌的编程风格指南。

2. 没有使用自动化检查

一旦你有了文档化的编程指南，就能进一步探索使用工具去自动检查代码是否遵守指南规范。众所周知，几乎所有的编程语言都有formatters、linters等，你可以将这些工具与代码预提交或者CI/CD等活动关联起来。

这些工具会对代码进行遍历，检查其是否违反编程规范，并通知代码作者。在提交PR前，作者需要解决这些规范和格式问题，这样就能很大程度降低代码评审中所出现的干扰。交给自动化完成的工作越多，作为评审人的团队成员就有更多时间去关注代码中的大问题，这些问题包括设计缺陷、实现缺失等等。

3. 不做自我审查

在要求其别人对自己的代码进行评审前，代码作者首先要自己检查一遍所做的更改。这就是所谓的“自我审查”，类似于我们在给别人发送电子邮件前先校勘一遍。

在实践中，审查自己的代码是一件很有挑战性的事情，因为会出现心理盲点（对自己代码中的缺陷，你可能心理上容易无意识地忽略掉。）以下这些方法，可以帮你更好的进行自我审查：

• 在不指定任何代码评审员的情况下提交PR，过几个小时后，自己再回来看看这部分代码，这样你会以全新的目光重新审视自己的代码更改。
• 不要以一目十行的方式随意地快速浏览自己做出的代码更改，而是要刻意谨慎地去逐行仔细检查这些更改。
• 按照一个检查清单去进行自我审查——比如，“代码是否遵循了编程指南？”，“我的代码是否已经涵盖了这些变更所需要支持的所有业务需求？”，“我是否为所有可能的用例编写了测试？” 等等。

4. 提交了庞大的PR

一个PR的评论数与PR包含的代码更改内容多少成反比。换句话说，越大的PR通常会获得越少的评论，而越小的PR则会获得越多的评论。

这是因为代码评审者在面对大PR所包含的过多内容，往往不堪重负，于是他们可能会快速浏览所有更改，从而快速结束此次code reviews。这种做法实际违背了code reviews的根本目的。而且，有时还会发生相反的情况，一个PR里内容过多，吓得代码评审者迟迟不敢行动。于是乎，很多天过去了，这个PR都没动静，并未获得任何评论意见。

将一个大PR分解成更小的代码块，让这些内容彼此分隔，这个做法是有意义的。这会让代码评审者的活动变得更正确且更快速。

5.提交了内容模糊的PR

一个代码评审者常常被要求去审查内容模糊或没有清晰功能描述的PR。然后，代码审查者不得不通过试图回忆来自于每日站会或问题跟踪器上的任务，才能理解这些d代码更改意味着什么。

所以，建议为提交的PR添加更多细节信息，比如：

• 这个PR包含了哪些更改？
• 代码评审者应该从哪些文件开始审查？
• 与之相关的问题跟踪器任务的链接
• 如果带来产品视觉上的变化，请附上屏幕截图

添加这些信息，将会为代码评审者提供更多的上下文，从而有助于他们更快速审查你的PR。

6.没有为完成评审设定时间期限

让提交的PR永远无法被合并的一种做法是，不为代码评审者完成评审工作设定任何时间期限。

请设定一个合理的时间期限，例如：

• 代码评审应在提交PR后48小时内完成
• 一个针对特定问题热补丁的代码评审必须在30分钟内完成

作者介绍：

Sheshbabu Chinnakonda，软件开发人员，问题解决者，喜欢构建新东西也喜欢修补东西。

英文原文：

How to prevent code reviews from slowing down your team