做不好Code Review的6大原因
极客时间编辑部
讲述：初明明大小：4.62M时长：05:03
你好，欢迎收听极客视点。
Code Review 如果实施不当，可能会严重拖慢团队的交付能力，许多代码更改会在 Code Review 活动中停留几天（甚至几周），最终影响产品的上市时间。为什么你的 Code Review 可能会耗时长久呢？软件开发人员谢什巴布·钦纳孔达（Sheshbabu Chinnakonda）将常见原因总结为如下 6 点。
1. 缺乏编程指南
每个团队都应该有一套人人同意的编程指南。这套编程指南应该包含命名规范、文件夹结构、代码格式以及单元测试、验证等活动的最佳实践。
如果没有明确的指导方针和约定规范，每个开发人员就会按照自己喜欢的方式去编写代码，这将导致在 Code Review 期间出现大量争论和分歧。如果你注意到有许多关于代码格式、命名规范等方面的评论意见，那么你就需要开始组织团队开展关于编程指南的讨论了。
2. 没有使用自动化检查
一旦你有了文档化的编程指南，就能进一步探索使用工具去自动检查代码是否遵守了指南规范。众所周知，几乎所有的编程语言都有 Formatters、Linters 等，你可以将这些工具与代码预提交或者 CI/CD 等活动关联起来。
这些工具会对代码进行遍历，检查其是否违反编程规范，并通知代码作者。在提交 PR 前，作者需要解决这些规范和格式问题，这样就能很大程度降低代码评审中所出现的干扰。交给自动化完成的工作越多，作为评审人的团队成员就有更多时间去关注代码中的大问题，这些问题包括设计缺陷、实现缺失等等。
3. 不做自我审查
在要求别人对自己的代码进行评审前，代码作者首先要自己检查一遍所做的更改。这就是所谓的“自我审查”，类似于你在给别人发送电子邮件前先校勘一遍。
在实践中，审查自己的代码是一件很有挑战性的事情，因为你可能会无意中忽略自己代码中的缺陷。以下这些方法，可以帮你更好地进行自我审查：
在不指定任何代码评审员的情况下提交 PR，过几个小时后，自己再回来看看这部分代码，这样你会以全新的目光重新审视自己的代码更改。
不要以一目十行的方式随意地快速浏览自己做出的代码更改，而是要刻意谨慎地去逐行仔细检查这些更改。
按照一个检查清单去进行自我审查。比如，“代码是否遵循了编程指南？”，“我的代码是否已经涵盖了这些变更所需要支持的所有业务需求？”，“我是否为所有可能的用例编写了测试？” 等等。
4. 提交了庞大的 PR
一个 PR 的评论数与 PR 包含的代码更改内容多少成反比。换句话说，越大的 PR 通常会获得越少的评论，而越小的 PR 则会获得越多的评论。
这是因为代码评审者在面对大 PR 所包含的过多内容，往往不堪重负，于是他们可能会快速浏览所有更改，从而快速结束此次 Code Review。这种做法实际违背了 Code Review 的根本目的。而且，有时还会发生相反的情况，一个 PR 里内容过多，吓得代码评审者迟迟不敢行动。于是乎，很多天过去了，这个 PR 都没动静，并未获得任何评论意见。
将一个大 PR 分解成更小的代码块，让这些内容彼此分隔，这个做法是有意义的。这会让代码评审者的活动变得更正确且更快速。
5. 提交了内容模糊的 PR
一个代码评审者常常被要求去审查内容模糊或没有清晰功能描述的 PR。然后，代码审查者不得不通过回忆来自于每日站会或问题跟踪器上的任务，才能理解这些代码更改意味着什么。
所以，建议为提交的 PR 添加更多细节信息，比如：
这个 PR 包含了哪些更改？
代码评审者应该从哪些文件开始审查？
与之相关的问题跟踪器任务的链接
如果带来产品视觉上的变化，请附上屏幕截图
添加这些信息，将会为代码评审者提供更多的上下文，从而有助于他们更快速审查你的 PR。
6. 没有为完成评审设定时间期限
让提交的 PR 永远无法被合并的一种做法是，不为代码评审者完成评审工作设定任何时间期限。
请设定一个合理的时间期限，例如：
代码评审应在提交 PR 后 48 小时内完成
一个针对特定问题热补丁的代码评审必须在 30 分钟内完成
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论