当你审查别人的代码时，你会寻找什么？

无论你是通过像 Upsource 这样的工具来审查代码，还是在同事讲解他们代码的过程中进行审查，在任何情况下，有些事情都比其他事情更容易评论。比如：

• 格式：空格和换行符在哪里？他们是否使用制表符或空格？大括号是如何布局的？
• 样式：变量/参数是否声明为最终变量/参数？方法变量是在使用它们的代码附近还是在方法的开头定义的？
• 命名：字段/常量/变量/参数/类名是否符合标准？名字是不是太短了？
• 测试覆盖率：是否有针对此代码的测试？

这些都是需要检查的有效事项——您想要最小化不同代码区域之间的上下文切换并减少认知负载，因此您的代码看起来越一致，就越好。

然而，让人类寻找这些可能不是组织中时间和资源的最佳利用，因为其中许多检查可以自动化。有很多工具可以确保代码的格式一致，遵循有关命名和最终关键字使用的标准，并发现由简单编程错误引起的常见错误。例如，您可以运行 IntelliJ IDEA 从命令行进行检查，因此您不必依赖所有团队成员在其 IDE 中运行相同的检查。

你应该寻找什么？

人类真正擅长什么样的事情？在代码审查中，我们能发现哪些我们无法委托给工具的东西？

事实证明，有数量惊人的东西。这当然不是一个详尽的清单，我们也不会在这里详细讨论其中任何一个。相反，这应该是你的组织中关于你目前在代码审查中寻找哪些东西，以及你应该寻找什么的对话的开始。

设计

• 新代码如何与整体架构相适应？
• 代码是否遵循 SOLID 原则、领域驱动设计和/或团队喜欢的其他设计范式？
• 新代码中使用了哪些设计模式？这些合适吗？
• 如果代码库混合了标准或设计风格，那么这些新代码是否遵循当前的做法？代码是朝着正确的方向迁移，还是遵循即将被淘汰的旧代码的示例？
• 代码是否在正确的位置？例如，如果代码与订单相关，它是否在订单服务中？
• 新代码能否重用现有代码中的某些内容？新代码是否提供了我们可以在现有代码中重用的内容？新代码是否引入了重复？如果是这样，是否应该将其重构为更可重用的模式，或者这在现阶段是否可以接受？
• 代码是否过度设计？它是否为现在不需要的可重用性而构建？团队如何平衡 YAGNI 的可重用性考虑因素？

可读性和可维护性

• （字段、变量、参数、方法和类的名称）是否真正反映了它们所代表的事物？
• 我可以通过阅读代码来理解代码的作用吗？
• 我能理解测试的作用吗？
• 这些测试是否涵盖了一个很好的 case 子集？它们是否涵盖快乐的道路和特殊情况？有没有考虑过的情况？
• 异常错误消息是否可理解？
• 令人困惑的代码部分是否被记录、注释或被可理解的测试所覆盖（根据团队偏好）？

功能性

• 代码真的做了它应该做的事情吗？如果有自动化测试来确保代码的正确性，那么这些测试是否真的测试了代码是否满足了约定的要求？
• 代码看起来是否包含细微的错误，例如使用错误的变量进行检查，或者不小心使用了 and 而不是 or？

你有没有想过......？

• 代码是否存在潜在的安全问题？
• 是否有需要满足的监管要求？
• 对于自动化性能测试未涵盖的领域，新代码是否引入了可避免的性能问题，例如对数据库或远程服务的不必要调用？
• 作者是否需要创建公共文档或更改现有帮助文件？
• 是否检查了面向用户的消息的正确性？
• 是否存在明显的错误会阻止它在生产中工作？代码是否会意外指向测试数据库，或者是否存在应该换成真实服务的硬编码存根？