评审作为知识传递
评审是成本最低的团队学习机制：评论里写清理由，新人学到的是规则而不只是结论；评审别人的代码，等于顺带熟悉陌生模块。用好这一点，可以逐步降低「只有少数人了解全貌」的单点依赖，也让接手和维护变得容易得多。
基本信息
| 评论结构 | 结论 + 依据 + 参考实现 |
|---|---|
| 轮换机制 | 避免长期只有少数资深成员参与评审 |
| 新人路径 | 先从测试与文档类改动开始评审 |
| 隐性产出 | 每个改动都是团队共享上下文的载体 |
典型使用场景
- 新人第一次评审：与资深评审人配对完成一轮，事后对照关注点复盘
- 跨模块改动：邀请目标模块维护者参与，顺带补齐模块认知
- 同一条评论反复出现：写进模块文档或自检清单
- 作者在描述里讲设计：读者顺带获得领域知识
- 轮岗与交接之前：用评审记录代替一次性的口头交接
带背景的评论怎么写
- 结论：建议改成什么
- 依据：为什么，属于哪一类问题
- 参考：团队规范的位置或已有实现
- 范围：必须改，还是可以后续处理
带背景的评审评论
带背景的评审评论
结论：这处建议从参数传入，而不是读取全局变量。
依据：该服务并发处理请求，全局变量会互相覆盖，属于正确性问题。
参考：团队规范的状态管理一节，src/cache.py 有同类写法可以沿用。
要点：给出规则出处与既有实现，让作者学到团队约定而不是只记住结论。知识传递动作
| 场景 | 动作 |
|---|---|
| 新人首次评审 | 配对资深评审人共同完成一轮，事后对照关注点复盘 |
| 跨模块改动 | 邀请目标模块维护者参与，顺带补齐模块认知 |
| 重复出现的评论 | 写进模块文档或评审清单，减少口头重复 |
解释理由确实比直接给结论费时间，但它把一次性的修正变成可复用的规则，长期一定划算。
评审记录也是交接材料：后来者翻一遍历史讨论，往往比通读代码更快理解某处设计为什么是这样。