理论上讲，Code Review 对开发人员来说是件好事。它能帮助我们：

• 提高我们代码的可读性
• 尽早发现漏洞和安全问题
• 提供一个安全网络，以确保所有任务都得到充分完成

但现实是，code review 对于所有相关人员来说通常是一种不舒服的体验，导致评审具有对抗性、无效，甚至根本没有评审。

下面是一个快速指南，帮助创建一个有效的 code review 过程。

我们为什么要进行 Code Review？

在进行 code review 评审流程时，首先要回答的问题是：我们 code review 的目的是什么？当你问这个问题时，你很快会发现有很多理由进行 code review 。甚至可能会发现团队中的每个人对为什么要 code review 都有不同的看法。

1. 发现漏洞
2. 检查潜在的性能或安全问题
3. 确保代码可读
4. 验证功能是否满足要求
5. 确保设计合理
6. 分享已实现的功能和更新设计的知识
7. 检查代码是否符合标准
8. ……或者其他几百个原因

如果团队中的每个人都有不同的“为什么”，那么他们会在代码中寻找不同的东西。这可能导致一些反模式：

• code review 需要很长时间，因为每个审查者都会发现一套需要解决的问题
• 审查者变得沮丧，因为每次审查都会根据谁审查它而提出不同类型的问题
• 审查员和代码作者之间可以进行乒乓球式的审查，因为每次新的迭代都会暴露出不同的问题

为代码审查设定一个单一的目标，可以确保参与审查的每一个人，无论是代码作者还是审查者，都了解审查的原因，并能集中精力确保他们的建议符合这一原因。

我们在寻找什么？

只有当我们理解了为什么要进行评审时，我们才能找出评审过程中我们想要寻找的东西。正如我们之前已经看到的那样，在评审过程中可能会有许多不同的事情需要我们去寻找，我们需要缩小范围，关注我们真正关心的事情。

例如，如果我们已经决定了代码审查的主要目的是确保代码的可读性和可理解性，那么我们将花费更少的时间来担心已经实现的设计，并更多地关注我们是否理解这些方法，以及功能是否处于有意义的位置。这个特定选择的副作用是，有了更可读的代码，更容易发现错误或不正确的逻辑。更简单的代码通常也具有更好的性能。

我们应该尽可能地自动化，所以人工代码审查员永远不应该担心以下问题：

• 格式和风格检查
• 测试覆盖率
• 性能是否满足特定要求
• 常见的安全问题

事实上，人工审查员应该关注的内容可能非常简单——代码“可用”吗？它是否：

• 可读
• 可维护
• 可扩展

这些都是无法自动化的检查。从长远来看，这些是开发人员最关心的代码功能。

然而，开发人员并不是唯一重要的人，最终代码需要完成一项工作。我们的业务关心的是：代码是否按照预期完成了工作？是否有自动化的测试或一组测试来证明这一点？

最后，它是否满足所谓的非功能性需求？考虑到监管要求（例如审计）或用户需求（如文档）等事项非常重要。

谁参与Code Review？

有了明确的目的和一套在评审中要查找的内容，我们就更容易决定哪些人应该参与评审。我们需要决定：

谁负责审查代码？

很容易认为应该是一位或几位资深或经验丰富的开发人员。但如果关注点是确保代码易于理解，那么初级开发人员可能是最适合审查的人——如果一位没有经验的开发人员都能理解代码中的情况，那么对每个人来说，理解起来可能就很容易了。如果审查的重点是分享知识，那么你可能会希望每个人都审查代码。对于其他目的的审查，你可能有一组评审人员，每次审查时从中随机选择几位。

谁负责审核签字？

如果我们有多于一个的评审员，那么了解谁最终负责表示评审完成是很重要的。这可能是一个人，一组特定的人，一定比例的评审员，特定代码区域的指定专家，或者评审甚至可以被单个否决停止。在高度信任的团队中，代码作者可能是决定何时反馈足够且代码已更新以充分反映所提出担忧的人。

谁来解决意见分歧？

评审可能有多于一个的评审者。如果不同的评审者给出了相互冲突的建议，作者应该如何解决？是由作者本人决定吗？还是有一个领导或专家可以仲裁并决定最佳方案？了解在代码评审过程中如何解决冲突是非常重要的。

Code Review 的时机

“时机”包含两个重要的组成部分：

我们什么时候开始 Code Review？

传统的代码审查发生在所有代码完成且准备投入生产时。通常，在审查完成之前，代码不会被合并到主干/主分支，例如拉取请求模型。但这并不是唯一的方法。如果代码审查是为了分享知识，那么审查可以在代码合并后进行（或者代码可以直接提交到主分支）。如果代码审查是一个增量审查，目的是帮助改进代码设计，那么审查将在实现过程中进行。一旦我们明白了：为什么要进行审查；我们在寻找什么；以及谁参与，我们就可以更容易地决定何时是进行审查的最佳时机。

什么时候完成 Code Review？

不明白何时完成审查是导致审查工作无限期拖延的主要因素。没有什么比永无止境的审查更让人沮丧的了，开发者感觉他们一直在做同一件事，但产品仍然没有进入生产环节。决定何时完成审查的指南将取决于参与审查的人员和审查进行的时间：

• 通过知识共享评审，每个人都有机会查看代码，然后可以签字确认。
• 通过网关评审，通常会有指定的单个高级人员（守门人）在解决所有问题后表示完成。

其他类型的评审可能需要一套标准，评审完成前需要通过这些标准。例如：

• 所有评论已通过代码中的修复解决
• 所有评论要么导致代码更改，要么导致问题跟踪器中的票据（例如，为新功能或设计更改创建票据；为即将推出的功能票据添加额外信息；或创建技术债务票据）
• 所有标记为阻止器的评论都已以某种方式解决，而未来需要观察或学习的评论则不需要“修复”

我们在哪里评论？

代码审核不一定要在代码审核工具中进行。结对编程是代码审核的一种形式。审核可以只是将同事拉过来，与他们一起浏览你的代码。审核可能通过查看分支并在文档、电子邮件或聊天频道中发表评论来完成。或者，代码审核可能通过 github pull 请求或代码审核软件来进行。

总结

进行代码审查时需要考虑很多事情，如果每次审查我们都担心所有这些事情，那么任何代码都无法通过审查过程。对我们来说，实施有效的代码审查过程的最佳方法是考虑：

• 我们为什么要进行审查？有了明确的目的，审查人员的工作就更容易了，代码作者也不会对审查过程感到意外。
• 我们在寻找什么？当我们有了目标，我们就可以在审查代码时创建一套更集中的需要检查的事项
• 谁参与了？谁负责审查，谁负责解决意见冲突，谁最终决定代码是否可以使用？
• 我们什么时候审查，什么时候审查完成？在编写代码的过程中，审查可以迭代发生，也可以在过程结束时进行。如果我们没有明确的指导，代码最终可以使用，那么审查可能会无限期地进行下去。
• 我们在哪里审查？代码审查不需要特定的工具，审查可以像让同事在办公桌前浏览我们的代码一样简单。

一旦这些问题得到回答，我们就应该能够创建一个对团队有利的代码审查过程。请记住，审查的目标是将代码投入生产，而不是证明我们有多聪明。