code-review

name	code-review
description	Comprehensive code review guidance — process, checklist, feedback conventions. Use when the user asks about code review flow, review criteria, best practices, or how to give/receive review feedback.
keywords	["code review","代码审查","PR","pull request","review","审查"]

代码审查指南

适用场景

当用户咨询代码审查流程、审查标准、最佳实践等问题时，参考本指南进行回答。

一、审查流程

1.1 提交前自查

开发者在提交 Code Review 前应完成以下自查：

1. 代码能正常编译和运行
2. 所有单元测试通过
3. 没有遗留的 TODO 或调试代码
4. 代码风格符合团队规范
5. 提交信息清晰描述了变更内容

1.2 审查步骤

1. 了解背景: 阅读 PR 描述和关联的需求/Bug 单
2. 整体浏览: 先看文件变更列表，理解改动范围
3. 逐文件审查: 从核心逻辑文件开始，关注重点代码
4. 运行验证: 对关键改动 checkout 代码本地运行验证
5. 给出反馈: 区分"必须修改"和"建议优化"

二、审查重点

2.1 功能正确性

• 逻辑是否正确，边界条件是否处理
• 异常情况是否妥善处理（空值、超时、并发）
• 数据校验是否充分

2.2 代码质量

维度	检查项
可读性	命名是否清晰，注释是否必要且准确
简洁性	是否有重复代码可提取，逻辑是否过于复杂
可维护性	是否易于扩展，依赖是否合理
一致性	是否遵循项目现有的代码风格和模式

2.3 安全性

• 用户输入是否做了校验和转义
• SQL 是否使用参数化查询（防注入）
• 敏感数据是否加密存储
• API 接口是否有鉴权

2.4 性能

• 是否有 N+1 查询问题
• 大数据量操作是否有分页
• 是否有不必要的重复计算
• 数据库查询是否使用了索引

三、反馈规范

3.1 反馈分级

• [MUST]: 必须修改，存在 Bug 或安全隐患
• [SHOULD]: 建议修改，影响代码质量
• [NICE]: 可选优化，锦上添花

3.2 反馈示例

好的反馈：

[MUST] 这里没有处理 user 为 null 的情况，当用户未登录时会抛出 NullPointerException。建议加一个空值检查。

不好的反馈：

这段代码有问题。

四、审查效率建议

• 单次审查不超过 400 行代码
• 审查时间不超过 60 分钟
• 使用工具辅助（静态分析、CI 检查）
• 重要改动应有两人以上审查