代码评审能显著降低缺陷率，但前提是它被真正执行。现实中常见的两种失败：一是小改动也要等三天才有人看，二是评审变成风格争论。两者都能用规则解决。
一、控制规模：小批量高频
一次评审几百行代码，没人会认真看。建议单次提交控制在 300 行以内，功能独立、目标单一。
- 一次评审解决一件事，不混入无关改动
- 大功能拆成多个小提交，分次评审
- 格式调整与逻辑改动分开提交
二、关注重点：先看这四类问题
- 正确性：边界条件、空值、并发、异常处理
- 安全性：参数校验、SQL 拼接、权限判断、敏感信息输出
- 可维护性：命名、分层、重复代码、必要的注释
- 性能：循环内查询、大对象序列化、无谓的全表扫描
风格问题交给工具
缩进、空格、命名风格这类问题应该由代码格式化工具处理。把它们留给人来争论，是评审时间最大的浪费。
三、区分"必改"与"建议"
| 标记 | 含义 | 处理 |
|---|---|---|
| 必改 | 存在缺陷、安全或稳定性风险 | 修改后方可合并 |
| 建议 | 优化方向，不影响正确性 | 可后续处理，记录在案 |
| 提问 | 需要作者说明设计意图 | 作者回复即可 |
四、时效与反馈方式
- 约定响应时限，如工作时间内 4 小时内首次反馈
- 意见要具体：指出问题 + 说明原因 + 给出方向
- 对事不对人，评论针对代码而不是作者
五、让评审沉淀成规范
同一个问题被指出三次以上，就该写进编码规范或做成静态检查规则。评审的目标不是每次都能发现问题，而是让某类问题不再出现。
#代码评审#质量保障#团队协作#软件事业部
