如何做好代码审查

在我从事开发人员的生涯中，我做过数百次代码审查。我学会了非常享受这项工作，因为它能让我了解其他人对我们代码库的看法。大多数时候，我都能从中学到新的东西。在本文中，我想分享一些关于如何做好代码审查，以及如何享受代码审查的技巧。

良好的管道

大多数团队都有一些代码风格规则和建议，用于统一代码库。无论如何，都不要强迫代码审查人员检查拉取请求是否符合这些规则。有一些工具可以检查 eslint 和 SonarQube。这些工具应该作为 PR 流程的一部分运行。

SonarQube 是一款能够提升团队中每个人代码审查质量的工具。它不仅可以发现代码风格问题，还能做更多。通过代码分析，它可以发现代码中最常见的错误。如果你从未关闭过资源？Sonar 会提醒你。我个人从不在 Sonar 完成工作之前进行代码审查。

你需要有一个具体的流程，每次有人创建 PR 或推送新的变更时都会运行。步骤大致如下。

• 编译代码
• 运行测试
• 运行 linting
• 运行 SonarQube
• 进行人工审核
• 合并到主代码库

天桥

和第一件事一样，在我的审核中，我会快速概览所有已更改的文件。我通常在拉取请求界面中进行此操作。在这个阶段，我会重点关注以下几点。

首先是代码的可读性。阅读体验如何？代码的功能是否一目了然？好的代码应该能够一眼就表达出它的目的。然后，我会尝试弄清楚这项变更是否符合相应的变更请求的要求。我会通读工单，并尝试匹配拉取请求中的所有要求。

在这个阶段，我不会深入研究实现细节。我会将这些细节留到后续阶段再说。

此阶段可能传达的要点：

• 变化不太可读
• 变更未涵盖要求，或变更请求单未随着要求的变更而更改
• 缺少测试

深入

简短的代码概览之后，我会得到一个需要深入研究的变更文件列表。我通常在 IDE 中执行此操作，以便更好地查看文件之间的关联，但对于大多数变更，在拉取请求的 Web UI 中执行此操作也可以。

我首先会问自己，如何解决这个问题，然后再进一步思考。我们的代码库中是否有类似（或相同）的代码？是否有一个（我们目前使用的）库可以用于此？如果有一个我们目前没有使用的库，是否值得添加它来解决这个问题？

测试回顾

不要忘记检查测试。所有用例都有效吗？这些测试是否有可能发现问题？断言是否可读？测试是否存在？

如果您作为审阅者觉得有可能添加更多测试来改进代码库，请不要害怕反击添加更多测试。

友善且有教育意义

无论你做什么，都不要傲慢、尖刻，也不要显得像个无所不知的人。如果提出的解决方案有效，但你希望采取不同的做法，你可以这样说，但也要批准该请求。你可以留下一些教育性的评论，但过多的评论可能会有害。考虑一下什么是重要的。不要为小事争论，人与人之间各不相同，观点也各异。

赞同

尽快批准，不完美也没关系。

这是您应该遵循的黄金法则。

想要获得更多类似的提示，您可以在Twitter上关注我。