评审是双向学习
代码评审常被当成单向把关：评审者提问题、作者改代码。实际它是双向的学习通道——作者从评论里学到团队标准与设计权衡，评审者从他人实现里看到不熟悉的写法和自己判断的盲区。把它当学习机制而不是单纯的质量门禁，意见会更具体，也更容易被接受。
作者侧的学习方式
- 把反复出现的评审意见整理成提交前个人检查清单
- 对不理解的评论先追问依据，而不是照改
- 把被否决的设计权衡记下来，下次在设计说明里主动交代
- 关注意见背后的模式，而不是只处理单条修改
- 把评审中确认的术语与命名统一到自己的代码与文档里
评审者侧的学习方式
- 遇到不熟悉的技术先提问再判断，避免用旧经验否定新写法
- 区分规则问题与个人偏好，偏好写成建议并说明适用场景
- 读作者的实现手法，记录可复用的写法与工具技巧
- 对自己不常写的语言或框架，先看团队规范再下结论
共识沉淀路径
| 同类意见重复出现 | 写入规范条目，或加进 lint / CI 规则 |
|---|---|
| 规范条目 | 落到模板、脚手架默认值与评审清单 |
| 新人高频疑问 | 整理成上手文档与示例代码 |
| 确认的团队偏好 | 先写进评审说明，再考虑做成自动化 |
把评论变成规则
把评论变成规则
评论：'提交信息格式不统一，回滚时很难定位改动'
→ 沉淀：接入 commitlint + 提交信息模板
评论：'空 catch 块反复出现，出问题时看不到上下文'
→ 沉淀：PMD / Checkstyle 规则提升为构建失败
评论：'魔法数字散落各处，改动范围看不出来'
→ 沉淀：写进编码规范，并加入评审检查清单
评论：'这个参数含义要翻实现才能懂'
→ 沉淀：补进接口注释模板，评审时按模板核对评审意见的三种归宿
| 意见类型 | 处理方式 | 落点 |
|---|---|---|
| 一次性设计权衡 | 记录决策与备选方案 | PR 描述、设计文档 |
| 反复出现的风格问题 | 写成规则或加入自动检查 | lint 配置、CI 门禁 |
| 个人偏好 | 写成建议并说明适用场景 | 评审评论，不强制 |
评论会被引用很多年：写之前想清楚受众是眼前的作者，还是半年后翻历史的同事；给出依据（规范条目、官方文档、可复现步骤）比只给结论更有用。
双向学习依赖心理安全：评审者允许被反驳，作者有异议时用最小复现样例或数据说话，而不是沉默照改或直接对抗。团队可定期回顾高频评审意见，把共识升级为规范与自动化规则。