你如何做Code Review 吗？

大家好，我是热心的大肚皮，皮哥。

一、前言

Code Review 可以帮助我们提高代码质量、减少项目问题，那么您知道 Code Review 可以从哪些地方开始审查吗？下文将列出一个详细的代码审查清单。它分为 7 个独立的部分，每个部分都会引导我们完成几个问题。

二、代码审查清单

1. 功能检查

• 此代码更改是否完成了它应该做的事情？
• 这个解决方案可以简化吗？
• 您是否会以在代码的可维护性、可读性、性能和安全性等方面有更好的方式解决问题？
• 代码库中是否有类似的功能？如果有，为什么不复用此功能？
• 这段代码是否遵循面向对象的分析和设计原则，如单一职责原则、开闭原则、Liskov 替换原则、接口隔离、依赖注入？

2. bug 检查

• 您能想到代码未按预期运行的任何用例吗？
• 您能想到任何可能破坏代码的输入或外部事件吗？

3. 依赖项检查

• 如果此更改需要在代码之外进行更新，例如更新文档、配置、自述文件，是否已完成？
• 这种变化是否会对系统的其他部分产生任何影响，是否已经兼容？
• 如果代码处理用户输入，它是否解决了跨站点脚本、SQL 注入等安全漏洞，它是否进行输入清理和验证？

4. 可用性和可访问性

• 从可用性的角度来看，提议的解决方案是否设计良好？
• API 是否有据可查？
• UI 是否可访问？
• API/UI 使用起来是否直观？

5. 表现

• 您是否认为此代码更改会对系统性能产生负面影响？
• 您是否看到任何提高代码性能的潜力？

6. 测试

• 代码是否可测试？
• 它是否有足够的自动化测试（单元/集成/系统测试）？
• 现有的测试是否合理地涵盖了代码更改？
• 是否有一些测试用例、输入或边缘用例需要额外测试？

7. 可读性

• 代码容易理解吗？
• 哪些部分让您感到困惑，为什么？
• 可以通过更小的方法来提高代码的可读性吗？
• 代码的可读性可以通过不同的函数/方法或变量名来提高吗？
• 代码是否位于正确的文件/文件夹/包中？
• 更多注释会使代码更易于理解吗？
• 是否可以通过使代码本身更具可读性来删除一些注释？
• 您认为某些方法应该被重组以拥有更直观的控制流程吗？

三、自审代码

代码审查清单不仅适用于代码审查人员。我们应该并首先成为自己的审查者，遵循代码审查最佳实践。

因此，在发送代码进行审核之前，请确保：

• 代码编译并通过静态分析，没有警告
• 代码通过所有测试（单元、集成和系统测试）
• 您已经仔细检查了拼写错误并进行了清理（评论、待办事项等）
• 您概述了此更改的内容，包括更改的原因和更改的内容
• 除此之外，作为代码作者，您应该通过与审阅者相同的代码审查清单。

四、关注重要问题

作为代码审查员，您的任务是首先寻找最重要的问题。结构或逻辑问题比代码格式等小问题更有价值。一份出色的清单将您的注意力引导到重要和最有价值的问题上。

五、自动化编码风格及约定

清晰的编码风格指南是在代码库中强制执行一致性的唯一方法。而且，一致性使代码审查更快，允许人们轻松更改项目，并使您的代码库保持可读性和可维护性。上文的审查清单没有介绍编码风格相关的内容，是因为我们建议使用自动化工具来强制遵守编码风格，节省编码风格的代码审查时间。

六、注意表达方式

最后，代码审查反馈的质量不仅取决于您在说什么，还取决于您怎么说。建议将您的反馈表述为建议而不是要求。例如，不要写“变量名应该是 removeObject ”，而是说“调用变量 removeObject 怎么样？”。

七、总结

代码审查清单以及围绕代码审查的明确规则和指南至关重要。代码审查清单可以使您的代码审查实践对您的团队更加有益，并显着加快代码审查速度。

本文详细介绍了 Code Review 的 7 种审查类型，帮助您在 Code Review 聚焦到重要和最有价值的问题上，提升 Code Review 质量。