代码审查的最佳实践

这看起来可能显而易见，但确保团队成员精通 Git 非常重要。经过精心编写的提交和只承担单一功能的提交，比起在多个提交中分散的许多更改，要容易得多。特别是将重构和业务逻辑混合在一起，审查起来非常麻烦。如果团队成员知道如何修正提交、打补丁修改他们在不同提交中的更改，并能编写良好的提交信息，那么最终的拉取请求就会更容易审查。

将拉取请求与启动该工作的相应问题进行关联。这有助于提供拉取请求的上下文。如果你使用第三方集成，将拉取请求与 Jira 工单、Azure Boards 工作项或你与 GitHub 连接的任何其他源进行关联。

让团队成员在开始工作时就创建草稿拉取请求。这样，团队就知道每个人在做什么。这也鼓励人们使用评论和提及请求反馈，提前开始审查。对更改的早期反馈有助于在最后阶段加快审查速度。

应该至少要求两个审批者。根据团队规模，更多的审批者越好，但一个是不够的。拥有多个审查员能为审查过程带来动态变化。我注意到，只是将审批者数量从一个改为两个，就对一些团队的审查实践带来了巨大的改进！

将审查视为同行审查。不要让资深架构师审查他人的代码！年轻的同事也应该审查同行的代码，以此来学习。一个好的做法是，将整个团队添加为审查员，并要求一定比例的审批（例如 50%），然后人们可以选择自己想审查的拉取请求。或者，你可以使用自动分配审查员的方式，随机分配团队内的审查任务。

许多审查步骤可以自动化，特别是格式化方面。使用良好的 linter 来检查代码格式（例如， https://github.com/github/super-linter ），或者编写一些测试来检查文档是否完整。使用静态和动态代码分析来自动发现问题。你自动化了越多琐碎的检查，审查就能更集中于重要的内容。

在合并之前，自动构建和测试你的更改。根据需要安装代码并进行测试。人们对更改不会破坏任何东西越有信心，他们对这个过程的信任就越大。使用自动合并功能，当所有审批和验证都通过时，自动合并并发布更改。高度自动化使得人们能够以更小的批量进行工作，从而使审查变得更加轻松。

一些工程师对做某事的正确方式有强烈的意见，辩论可能会迅速失控。你希望进行激烈的讨论以找到最佳解决方案，但也希望这些讨论能够以一种包容的方式进行，让团队中的每个人都能平等参与。制定审查指南和行为规范作为门槛非常有帮助。如果有人没有遵守规范，你可以指明这些规则。