代码审查或评审的最佳实践

作为开发人员，我们都知道代码审查在理论上是一件好事。他们应该帮助我们：

• 尽早发现错误和安全问题
• 提高代码的可读性
• 提供安全网以确保所有任务完全完成

现实情况是，代码审查对于每个参与者来说经常是一种令人不舒服的体验，导致审查变得好斗，无效甚至更糟，根本就不存在代码审查。 这是一个快速指南，可帮助您创建有效的代码审查过程。 为什么要进行代码审查？ 在审核您的代码审核流程时要回答的第一个问题是：我们的代码审核的目的是什么？当您提出这个问题时，您很快意识到执行代码审查的原因有很多。您甚至可能会发现团队中的每个人都对他们审核代码的原因有不同的看法。他们可能会认为他们正在审查:

1. 找到错误
2. 检查潜在的性能或安全问题
3. 确保可读代码
4. 验证功能是否满足要求
5. 确保设计合理
6. 分享已实施功能和更新设计的知识
7. 检查代码是否符合标准......或其他数百个原因之一

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

• 代码审查需要很长时间，因为每个审阅者都会发现需要解决的一组不同问题
• 审稿人变得失去动力，因为每次审核都会根据审核人员的不同而引发不同类型的问题
• 审查可以在审查者与代码作者之间进行踢皮球，因为每次新迭代都会暴露出一组不同的问题

为您的代码审核提供单一目的可确保参与审核的每个人，无论他们是代码作者还是审核者，都知道审核的原因，并可以集中精力确保他们的建议符合这一原因。 我们在找什么？ 只有当我们理解为什么要进行审核时，我们才能找出我们想要在审核期间寻找的内容。正如我们已经开始看到的那样，在审查过程中我们可以寻找大量不同的东西，我们需要缩小我们真正关心的具体事项。 例如，如果我们确定我们的评论的主要目的是确保代码可读和可理解，我们将花费更少的时间来担心已经实现的设计，并花更多的时间关注我们是否理解方法以及功能是否在一个有意义的地方。这个特殊选择的好处是，通过更易读的代码，更容易发现错误或错误的逻辑。更简单的代码通常也是更好的性能。 我们应该尽可能地自动化，因此人工代码审查员永远不应该担心以下情况：

• 格式化和样式检查
• 测试范围
• 如果性能满足特定要求
• 常见的安全问题

事实上，人工代码审查员应该关注的事情可能相当简单 - 代码是否“可用”？

1. 可读性
2. 可维护性
3. 扩展性

这些都是无法自动化检查的。从长远来看，这些是开发人员最重要的代码功能。 我们的业务关心：代码是否做了应该做的事情？是否有自动测试或一组测试来证明它？ 最后，它是否符合所谓的非功能性要求？如果进行这些检查，重要的是要考虑诸如监管要求（例如审计）或用户需求（例如文档）之类的事情。 谁参与了代码审查？ 有了明确的目的和一系列要在审查中寻找的东西，决定谁应该参与审查要简单得多。我们需要决定： 1. 谁评审代码？ 人们很容易认为应该是一个或多个资深或经验丰富的开发人员。但是，如果重点是确保代码易于理解，那么初级人员可能是正确的审查人员 。 如果没有经验的开发人员能够理解代码中发生的事情，那么每个人都可能很容易理解。 如果评审的重点是分享知识，那么您可能希望每个人都查看代码。对于其他用途的评审，您可能会有一组评论者，其中一些评审会随机挑选。 2.谁签署评审？ 如果我们有多个评审者，重要的是要了解谁最终负责说评审已经完成。这可以是一个人，一组特定的人，一定数量的评审者，特定代码区域的特定专家，或者甚至可以通过一次否决来终止审查。在具有高度信任的团队中，代码作者可能是决定何时足够的反馈足够并且代码已经更新以充分反映所引起的关注的人。 3. 谁解决了意见分歧？ 评审可能有多个评审者。如果不同的评审人有相互矛盾的建议，作者如何解决这个问题呢？由作者决定吗？或者是否有可以仲裁和决定最佳课程的领导或专家？了解在代码审查期间如何解决冲突非常重要。 什么时候审查？ “何时”有两个重要组成部分： 1. 我们什么时候审查？ 传统的代码审查在所有代码完成并准备好投入生产时发生。在审核完成之前，代码通常不会合并到主干/主服务器，例如拉取请求模型。这不是唯一的方法。如果代码审查用于知识共享，则可以在合并代码之后进行审核（或者代码可以直接提交给主代）。如果代码审查是一个增量审核，应该有助于改进代码的设计，那么审核将在实施过程中发生。一旦我们知道： 我们为什么要做审查; 我们正在寻找什么 ; 和谁参与，我们可以更容易的时候是进行审评的最佳时机决定。 2 审查何时完成？ 不了解审核何时完成是导致审核无限期拖延的主要因素。没有什么比永远不会结束的查更令人失去兴趣，开发人员觉得他们一直在做同样的事情而且还没有投入生产。决定审核何时完成的指导原则取决于谁参与审核，以及审核何时进行：

• 通过 知识共享评论，一旦每个人都有机会查看代码，就可以签名
• 通过网关评论，通常一名指定的高级管理人员（守门人）表示，当所有要点得到解决时，它都是完整的

其他类型的评论可能有一组标准需要在评审完成之前通过。例如：

• 所有注释都通过代码中的修复程序解决
• 所有评论都导致代码更改，或导致问题跟踪器中的故障单（例如，创建新功能或设计更改的故障单;为即将发布的功能故障单添加其他信息;或创建技术债务故障单）
• 标记为showstoppers的评论都以某种方式得到了解决，未来需要学习的观察或教训的评论不需要“修复”

我们在哪里审查？ 代码审查不必在代码审查工具中进行。结对编程是代码审查的一种形式。审核可能只是将同事拉到一边并随身携带代码。可以通过签出分支并在文档，电子邮件或聊天频道中发表评论来完成评论。或者代码审查可能通过github pull请求或一段代码审查软件发生。 总结 在进行代码审查时需要考虑很多事情，如果我们为每次代码审查都担心所有这些问题，那么任何代码都几乎不可能通过审核流程。实施适合我们的代码审查流程的最佳方法是考虑：

• 我们为什么要做审查？评审人的工作更加容易，目的明确，代码作者在审核过程中会有更少的令人讨厌的意外
• 什么是我们寻找什么？当我们有目的时，我们可以创建一个更集中的事物来检查代码
• 谁参与了？谁负责审核，谁负责解决意见冲突，谁最终决定代码是否合适？
• 审核什么时候完毕？在处理代码时或在流程结束时，可能会反复进行审核。如果我们没有关于代码何时最终可行的明确指导，那么审查可能会永远持续下去。
• 我们在哪里审核？代码审查不需要特定的工具，审查可以像通过我们走进同事办公桌一样简单。

一旦这些问题得到解答，我们就应该能够创建一个适合团队的代码审查流程。请记住，审核的目标应该是将代码投入生产，而不是证明我们有多聪明。 来源：https://trishagee.github.io/post/codereviewbest_practices/