大家好，我是热心的大肚皮，皮哥。
一、前言
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 质量。
