在代码审查中寻找什么

让我们谈谈代码审查。如果您只花几秒钟搜索有关代码审查的信息，您会看到很多关于为什么代码审查是一件好事的文章（例如， Jeff Atwood 的这篇文章）。

您还会看到很多关于如何使用 Code Review 工具（例如我们自己的 Upsource ）的文档。

您很少看到的是在审查其他人的代码时要查找的内容的指南。

可能没有关于要寻找什么的明确文章的原因是：有很多不同的事情需要考虑。而且，与任何其他需求集（功能性或非功能性）一样，各个组织对每个方面都有不同的优先级。

由于这是一个很大的话题，本文的目的是概述审阅者在执行代码审阅时可能需要注意的一些事情。确定每个方面的优先级并始终如一地检查它们是一个足够复杂的主题，足以单独成为一篇文章。

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

无论您是通过 Upsource 之类的工具审查代码，还是在同事遍历他们的代码期间审查代码，无论在何种情况下，有些事情比其他事情更容易评论。一些例子：

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

这些都是需要检查的有效内容——您希望最大程度地减少不同代码区域之间的上下文切换并减少认知负担，因此您的代码看起来越一致越好。

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

你应该找什么？

人类真正适合做什么样的事情？我们可以在代码审查中发现哪些我们无法委托给工具的内容？

事实证明，事情的数量多得惊人。这当然不是一个详尽的列表，我们也不会在这里详细介绍其中的任何一个。相反，这应该是您组织中关于您当前在代码审查中寻找哪些内容以及您或许应该寻找的内容的对话的开始。

设计

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