Code Review = 知识共享机制
解决什么问题：Code Review 沦为形式或战场—— CR 的真正目的不是抓 bug，而是教学 + 心智模型同步。
业务问题
真实场景
场景 1：CR 沦为"礼貌通过"
团队：
- PR 提交 → 24h 内 LGTM（不细看）
- 没人真正理解改动
- 6 个月后没人能维护这段代码
- "为什么这么写？" → "不知道，PR 过的"
CR 沦为形式 = 知识从未传播场景 2：CR 沦为"风格之争"
团队：
- PR 提交 → 100 条评论（多数是风格）
- 实质问题被淹没
- 作者疲惫
- 团队关系紧张
CR 沦为审判 = 知识被压抑失败模式
| 失败模式 | 后果 |
|---|---|
| 快速 LGTM | 知识不传播 |
| 风格洁癖 | 实质问题被忽视 |
| 个人偏好 | 团队疲惫 |
| 拖延 | 阻塞作者 |
控制论视角
Ch 21："多级分散系统的协调" + Ch 4 §4.6："反馈环路"
CR = Ch 21 跨团队协调机制
- 提交 = 信号
- Review = 反馈
- LGTM = 协调通过
CR 的本质：
- 不是 QA（不是找出 bug）
- 是教学（不是审判）
- 是知识传播（不是质量控制）核心概念
CR 的 3 个目的（按重要性）
1. 知识共享（最重要）
- 作者：强迫清晰表达
- Reviewer：理解代码 + 团队思维
- 团队：心智模型同步
2. 代码质量
- 设计 review
- 风格一致
- 测试覆盖
3. 发现 bug（最少价值）
- 但常被高估
- 静态分析更高效CR 流程最佳实践
1. 作者自测
- 自己先 review
- 自我批评
- 写清晰的 PR 描述
2. PR 提交
- 小而专（< 400 行）
- 单一目的
- 完整描述（why > what）
3. Reviewer 响应
- < 24h（24 小时规则）
- 友好 + 具体
- 区分 must-have / nice-to-have
4. 多轮迭代
- 解决评论
- 解释 trade-offs
- 不卑不亢
5. LGTM + 合并
- 自动测试通过
- 必要人数 LGTM速度原则
快速 CR 的价值：
- 减少 WIP
- 减少 merge conflict
- 加快反馈循环
24 小时规则：
- 第 1 个工作日响应
- 否则 LGTM auto-apply
- 例外：大型 PR / 不熟悉领域工程实践
决策 1：何时用哪种 CR 严格度
情况 1：核心代码（auth/billing/...）
- 必须 2+ LGTM
- 团队负责人 review
- 严格审查
情况 2：普通功能代码
- 1 LGTM
- 任何团队成员
- 中等审查
情况 3：实验性代码
- 单人 review
- 不强制
- 快速合并决策 2：如何写出好 PR
原则：
- < 400 行（理想 200 行）
- 单一目的
- 完整 commit message
- 描述"为什么"（不是只"做什么"）
- 自测 + CI 通过
PR 模板：
- Context（背景）
- Changes（改动）
- Testing（测试）
- Risks（风险）反模式 vs 正模式
| 反模式 | 正模式 |
|---|---|
| "LGTM"（不读） | 真正理解 |
| "改一下命名"（风格） | 关注实质 |
| "我不会这么写"（个人） | 说明 why |
| "等我有空再看"（拖延） | 24h 规则 |
| 100 条评论 | 友好 + 关键 |
性能指标
| 指标 | 衡量 | 健康值 |
|---|---|---|
| CR 时间 | 平均响应时间 | < 24h |
| PR 大小 | 平均行数 | < 400 |
| 评论数量 | 平均评论 | < 20 |
| LGTM 速度 | 第一次提交到 LGTM | < 2 天 |
边界判断
何时用严格 CR
- 核心代码
- 安全敏感
- 数据迁移
- 跨团队影响
何时用快速 CR
- 实验性
- 紧急修复
- 文档改动
- 小 bug fix
关键洞察
- CR 是教学——最大价值是知识传播，不是 bug 抓取。
- 小 PR 优于完美——400 行 PR 比 4000 行更易 review。
- 速度 > 完美——24h 规则避免阻塞。
- 友好 > 严谨——团队关系比单一 PR 重要。
- 与 cybernetics 同构——Ch 21 跨团队协调 = CR 的本质。