认识达内从这里开始

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

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

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

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

那哪些要点是只能由人工进行审查而不能依靠工具的呢？达内长沙IT培训继续来说：

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

设计

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

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

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

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

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

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

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

可读性和可维护性

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

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

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

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

错误信息是否可被理解？

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

功能

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

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

你是否考虑过……？

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

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

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

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

你对性能的需求是什么，你是否考虑了安全问题？

总结

代码审查是一个很好的方式，不仅确保了代码质量和一致性，也在团队中或团队间分享了项目知识。即使你已经自动化了基础的校验，还有许多不同代码、设计的方面需要考虑。代码审查工具，如Upsource，通过在每个代码提交的检查中高亮可疑的代码并分析哪些问题已经被修复，新引入哪些问题，可以帮你定位一些潜在的问题。工具也可以简化流程，因为它提供了一个平台来讨论设计和代码实现，也可以邀请审查者、作者和其他相关人员参加讨论直到达成共识。

最后，团队需要花时间决定代码质量的哪些因素对他们是重要的，也需要专家人工决定哪些规则应用到各个代码审查中，参与到审查中的每个人都应该具备并使用人际交往的技巧，如积极的反馈、谈判妥协以达到最终的共识，即代码应该怎么样才“足够好”可以通过审查。