在本文中，我们将简要介绍13种代码审查标准，这些标准可以极大地帮助改善软件的运行状况并保持开发人员满意。

顾名思义，

代码审查

是一个过程，其中一个或多个开发人员审查或筛选另一位开发者（作者）编写的代码，以确保：

这就是为什么代码审查是软件开发的关键部分的原因。代码审阅者充当代码库管理员，负责确定代码是否处于要成为代码库的一部分并进入生产的状态。

Google以其卓越的技术而著称，它们具有有效的代码审查标准，这些标准似乎突出了审查代码时要记住的一些要点。在Google，代码审查的主要目的是确保Google代码库的整体代码运行状况随着时间的推移而不断改善。

这是您在查看更改列表时要记住的事项列表。

审查标准

每个更改列表（Pull Request）都会改善系统的整体运行状况。想法是，由于进行了如此小的改进，每次合并后，软件或代码库的运行状况都会得到改善。

首先，不要延迟推送（合并）更好的代码。不要指望代码是完美的。如果它的状况可以改善系统的整体运行状况，则请推送。

“这里的关键是没有'完美'的代码，只有更好的代码。”

如果您不在一项重点任务的中间，那么请在代码完成后立即进行检查；但是，一个工作日是响应拉取请求所需的最长时间。预计变更列表将在一天之内获得多轮的部分/完整代码审查。

通过尽可能共享知识和经验，在代码审查期间提供指导。

始终牢记，编码标准此类文档是代码审查期间的绝对权威。例如，要在制表符和空格之间保持一致性，可以引用编码约定。

通过遵循样式指南和编码标准文档中商定的最佳实践，并寻求其他在产品领域具有更多知识和经验的人的建议，来解决冲突。根据严重性，处理冲突有所不同。

如果您的评论是可选的或次要的，请在评论中进行说明，然后由作者决定是解决还是忽略它们。作为代码审阅者，您至少可以建议在没有样式指南或编码标准的情况下，更改列表（请求）与其余代码库保持一致。

如果更改列表（Pull Request）更改了用户界面，则除了代码查看之外，还必须进行演示以确保外观上的所有外观均符合预期并与模拟匹配。

对于前端变更列表（Pull Request），始终建议进行演示/演练，或确保变更列表还包括必要的UI自动化测试，以验证添加/更新的功能。

除非紧急情况，否则拉取请求（更改列表）应伴随所有必要的测试，例如单元，集成，端到端等。

紧急情况可能是需要尽快修复的错误或安全漏洞，以后可以添加测试。在这种情况下，请确保创建了适当的问题，并确保有人在完成热修复或部署后立即拥有所有权才能完成。

没有足够的理由跳过测试。如果由于时间限制，某些目标有无法实现的风险，那么解决方案不是跳过测试，而是要对可交付成果进行范围界定。

如果您正处于重点工作中，请不要打扰自己，因为这可能需要很长时间才能恢复正常。换句话说，打断专注的开发人员所付出的代价比让开发人员等待代码审查要高得多。在计划的休息时间（例如午餐，咖啡等）之后进行代码检查。

期望并非总是在同一天完成并合并整个代码审查过程。重要的是迅速给作者一些反馈。例如，您可能无法进行完整的检查，但是您可以快速指出一些可以研究的内容。这将极大地减少代码审查期间的挫败感。

查看分配给您检查的每一行代码。不要对人工编写的类和方法做任何假设，并且应该确保您了解代码在做什么。

确保了解您正在检查的代码。如果没有，请进行澄清或要求代码演练/解释。如果您有部分代码不具备审阅的资格，请确保还有其他合格的开发人员可以审阅代码的那些部分。

从更广泛的背景来看变化通常是有帮助的。例如，更改了文件，并添加了四行代码。不要只查看四行代码；相反，请考虑查看整个文件并检查新添加的内容。它们会降低现有代码的质量，还是会使现有功能成为重构的候选对象？

如果不在函数/方法或类的上下文中检查此类简单的添加项，则随着时间的流逝，您将继承一个类，该类是不可维护的，超级复杂的，难以测试的，无法完成的所有工作，并且难以扩展或重构。

请记住，随着时间的推移，很少的改进加起来就可以产生具有最少数量缺陷的优质产品，同样，随着时间的流逝，轻微的代码降级或技术负担也会加重并导致产品难以维护和扩展。

如果您在变更列表中看到了一些不错的东西，请别忘了喊出作者的出色作品并鼓励他们。这是我个人以前从未做过的事情。代码审查的目的不仅应该是发现错误，还应该鼓励和指导开发人员所做的出色工作。

至关重要的是，在代码审阅期间，您要善良，清晰，礼貌和尊重，同时也要对作者非常清楚和乐于助人。查看代码时，请确保对代码而不是开发人员做出评论。

每当代码审阅意见提出替代方法或进行标记时，至关重要的是要解释原因并根据您的知识和经验提供示例，以帮助开发人员了解您的建议将如何帮助提高代码质量。

当建议修复或更改时，请在如何指导作者修复代码方面找到适当的平衡。例如，我很欣赏指导，解释，一些提示或建议，而不是整个解决方案。