Code Review（CR）即代码审查，是一种风险预防和质量保障机制，目的是通过评审代码发现潜在问题或不合理设计。
但在实际工作中，CR 很容易变成形式主义，主要有下面几方面原因：
- 项目交付压力大导致 CR 被忽视。
- 团队内部不愿意投入时间和精力。
- 缺乏有效方法和工具，CR 效率低，达不到预期效果。
如何合理进行 CR 并提高 CR 的效率？下面是自己总结的一些经验，仅供参考，适合自己的才是最好的。
两个观点
CR 不是形式主义，也不需要面面俱到，避免陷入完美主义。
CR 的高效实施离不公司制度和团队的支持，建立完善合理的 CR 流程和持续改进机制很重要。
为什么要做 CR ？
CR 的核心目标和关注点，主要有以下几个方面：
- 保证代码质量：关注点主要是代码的可读性、可维护性、性能、并发、安全、日志输出等，整体是否符合统一的开发规范。
- 规避潜在风险：关注点是设计是否合理，避免不合理的设计长期影响项目，直至变成不可逆的技术债务。
- 团队知识分享：通过相互交流，可以更深入了解业务逻辑，学习优秀的解决思路，有利于提高整体技术水平。
功能正确是 CR 的前提，但不是重点，应该在本地测试通过之后，才进行 CR 。
如何提高 CR 效率 ？
- 完善并统一开发规范：如代码可读性规范、设计规范、静态代码扫描工具（SonarQube）等，这一步可以过滤掉大部分低级问题。
- 明确任务类型：按重要性对任务进行标记， 一般情况下，简单任务不用进行 CR，如单表的 CURD，可有效减少 CR 工作量。
- 重视设计方案评审：根据实际情况，对高、中优先级任务提前进行设计评审，在实际开发之前解决不合理设计，避免开发后再返工。
- 制定合理的检查清单：专注 CR 的核心目标和关注点。
检查清单
| 检查项 | 关注点 |
|---|---|
| 内容 | 实现了什么功能？解决了什么问题？ |
| 整体设计 | 是否遵循设计原则？API 是否设计合理？是否合理使用开源工具和中间件？ |
| 非功能性 | 是否处理极端操作、资源关闭、慢 SQL、线程安全、非法请求、数据安全等问题？ |
| 可读性 | 命名是否规范？注释是否清晰？关键日志是否输出？ |
| 可维护性 | 调用链是否简单？是否过度设计？是否清晰明了？ |
| 稳定性 | 超时如何处理？重试是否合理？是否有熔断机制？是否需要压测？ |
结果反馈
- CR 提出的改进项，及时处理。
- 比较典型的问题，补充到检查清单中。
- 持续跟进，问题要闭环。
最佳实践
- CR 前应该先自行检查代码，确保功能正确，符合开发规范。
- 关注核心内容，避免纠结无关的细节。
- 一次 CR 的内容，最好是单个独立且完整的功能。
- 避免完美主义，结合实际情况，不追求所有代码都是最优解，只要代码方向正确且符合规范，就是可以接受的。
