译者｜周元昊

　　代码审查是一个很好的方式，不仅确保了代码质量和一致性，也在团队中或团队间分享了项目知识。代码审查者在审查代码时有非常多的东西需要关注，这些方法，能助你在代码审查时更加高效。

　　本文要点

代码审查者在审查代码时有非常多的东西需要关注。一个团队需要明确对于自己的项目哪些点是重要的，并不断在审查中就这些点进行检查。

人工审查代码是十分昂贵的，因此尽可能地使用自动化方式进行审查，如：代码格式、代码样式、检查常见bug、确定常见安全问题以及运行自动化测试。

当针对性能进行审查时，atv，了解系统的性能需求是明确潜在问题的关键。

一些简单的人工检查可以显著提升应用的安全性。

代码审查是应该在互相沟通中进行讨论的，而不是相互对抗。预先确定哪些是要点哪些不是，可以减少冲突并拟定预期。

　　写在前面

众所周知，在团队中进行代码审查（Code Review）可以提升代码质量，分享项目知识、明确责任，最终达到构建更好的软件、更好的团队。如果你花几秒钟搜索代码审查的相关信息，你会看到许多关于代码审查带来的价值的文章。也有许多方法来进行代码审查：在GitHub中提pull request，或使用像JetBrains的Upsource之类的工具。然而即使拥有清晰的流程和正确的工具，还遗留了一个大问题需要解决——我们需要找寻哪些问题。

可能没有明确关于“我们需要找寻哪些问题”的文章，是因为有许多不同的要点需要考虑。正如任何其他的需求，各个团队对各个方面都有不同的优先级。

本文的目标是列出一些审查者可以找寻的要点，而各个方面的优先级就因各个团队而异了。

在我们继续之前，让我们考虑一下大家在代码审查时会讨论到的问题。对于代码的格式、样式和命名以及缺少测试这些问题是很常见的几点。如果你想拥有可持续的、可维护的代码，这些是有用的检查点。然而，在代码审查时讨论这些就有些浪费时间，因为很多这样的检查可以（也应该）被自动化。

那哪些要点是只能由人工进行审查而不能依靠工具的呢？

回答是有惊人数量的点只能由人工进行审查。在本文剩下的部分，我们会覆盖一系列广泛的特性，并深入其中的两点具体的区域：性能和安全。

　　关于设计

如何让新代码与全局的架构保持一致？

代码是否遵循SOLID原则，是否遵循团队使用的设计规范，如领域驱动开发等？

新代码使用了什么设计模式？这样使用是否合适？

基础代码是否有结合使用了一些标准或设计样式，新的代码是否遵循当前的规范？代码是否正确迁移，或参照了因不规范而淘汰的旧代码？

代码的位置是否正确？比如涉及订单的新代码是否在订单服务相关的位置？

新代码是否重用了现存的代码？新代码是否可以被现有代码重用？新代码是否有重复代码？如果是的话，是否应该重构成一个更可被重用的模式，还是当前还可以接受？

新代码是否被过度设计了？是否引入现在还不需要的重用设计？团队如何平衡可重用和YAGNI(You Ain’t Gonna Need It)这两种观点？

　　可读性和可维护性

字段、变量、参数、方法、类的命名是否真实反映它们所代表的事物。

我是否可以通过读代码理解它做了什么？

我是否理解测试用例测了什么？

测试是否很好地覆盖了用例的各种情况？它们是否覆盖了正常和异常用例？是否有忽略的情况？

错误信息是否可被理解？

不清晰的代码是否被文档、注释或容易理解的测试用例所覆盖？具体可以根据团队自身的喜好决定使用哪种方式。

　　关于功能

代码是否真的达到了预期的目标？如果有自动化测试来确保代码的正确性，测试的代码是否真的可以验证代码达到了协定的需求？

代码看上去是否包含不明显的bug，比如使用错误的变量进行检查，或误把and写成or？

　　你是否考虑过……？

是否需要满足相关监管需求？

作者是否需要创建公共文档或修改现存的帮助文档？

是否检查了面向用户的信息的正确性？

是否有会在生产环境中导致应用停止运行的明显错误？代码是否会错误地指向测试数据库，是否存在应在真实服务中移除的硬编码的stub代码？

你对性能的需求是什么，你是否考虑了安全问题？这些是需要覆盖到的重大区域也是至关重要的话题，下面让我们仔细看下这两点。

　　关于性能

让我们深入探讨下性能，这是一个真正能从代码审查中获益的方面。