代码评审是什么
代码评审用于找缺陷、传播知识与统一规范，是质量与知识流动的双重机制。有效实践包括小批量提交、自动化检查前置、明确评审时限与责任，避免评审变成瓶颈。评审发现的并不只是逻辑缺陷，更多是可维护性、边界条件与知识扩散。评审等待时间往往比评审本身更耗时，因此优化响应速度通常比要求更深入的评审更见效。
基本信息
| 目标 | 缺陷、知识、规范三合一 |
|---|---|
| 实践 | 小 PR、自动化前置、限时评审 |
| 度量 | 评审等待时间、返工率、PR 规模 |
| PR 规模建议 | 单次改动控制在数百行以内 |
| 时限建议 | 24 小时内给出首轮反馈 |
| 前置条件 | 静态检查与单测先通过 |
典型使用场景
- 功能开发：每个小改动一个 PR，便于逐条评审与回滚
- 缺陷修复：附上复现步骤与测试用例，关注回归风险
- 架构调整：先评审设计文档，再提交代码，避免返工
- 新人产出：评审同时承担培训作用，重点解释原因
- 安全敏感改动：鉴权、加密、数据导出等改动安排专人复核
- 规范统一：把反复出现的评审意见沉淀为规范与自动化检查
PR 检查清单示例
PR 检查清单示例
□ 变更范围单一、描述清晰
□ 自动化测试与静态检查通过
□ 安全敏感点已标注
□ 回退方式说明
□ 关联需求或缺陷编号评审关注点优先级
| 关注点 | 说明 | 示例 |
|---|---|---|
| 正确性 | 逻辑是否满足需求与边界条件 | 空值、并发与异常分支 |
| 安全性 | 鉴权、输入校验与敏感数据 | SQL 拼接、越权访问 |
| 可维护性 | 命名、结构与重复代码 | 复制粘贴出的重复逻辑 |
| 测试覆盖 | 新分支是否有对应用例 | 新逻辑无自动化测试 |
| 回退与兼容 | 是否影响存量数据与接口 | 字段变更未做兼容处理 |
评审等待时间是交付前置时间的重要组成部分：优化评审响应，往往比要求更深入的评审更能缩短前置时间。