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，软件开发人员，问题解决者，喜欢构建新东西也喜欢修补东西。
英文原文：
评论