结对审查

为什么

何时使用

如何做

1. 识别需结对审查的 PR
   - 影响现有数据的数据库迁移
   - 认证或安全变更
   - 支付或计费变更
   - 新架构模式或重大重构
   - 设计比行更重要的任何 PR

2. 安排 30-60 分钟审查会
   - 共享屏（Zoom、Tuple、VS Code Live Share）
   - 作者走变更、审查者问问题
   - 聚焦设计非行——linter 处理行

3. 讨论权衡
   - 考虑了什么替代？为何选这个？
   - 失败模式是什么？系统如何降？
   - 性能特征是什么？会扩展吗？
   - 迁移路径是什么？如何回滚？

4. 记决定
   - 录会（同意）或记笔记
   - 为决定写 ADR（架构决定记录）
   - PR 中链 ADR 使未来读者懂为什么

5. 异步审查跟进细节
   - 结对审查抓设计问题
   - 异步审查抓行级问题
   - 两者都用——互补非替代

示例

// 场景: 将 users 表拆为 users 和 user_profiles 的数据库迁移。
// 这高风险因:
// - 影响数据库每行
// - 改每查询依赖的 schema
// - 错意味数据丢失或宕机

// 异步审查会漏:
// - 迁移锁表吗？多久？
// - 迁移期间跑的查询怎样？
// - 出问题如何回滚？
// - 部署顺序——先迁移还是先代码？

// 结对审查会（30 分钟）:
// 作者: "我将 users 拆为 users 和 user_profiles。
//   迁移加新表、复制数据、然后删旧列。"
// 审查者: "复制花多久？我们有 1000 万行。"
// 作者: "约 5 分钟。锁表。"
// 审查者: "5 分钟宕机不可接受。能批量避免锁吗？"
// 作者: "能、每批 1 万短锁复制。总迁移 30 分钟但应用保持上。"
// 审查者: "迁移期间从 users 读的查询呢？"
// 作者: "我更新代码过渡期读两表、之后清理。"
// 审查者: "好。写为 ADR 链 PR。"

// ADR: 2024-01-15-split-users-table.md
"""
# 拆 users 表为 users 和 user_profiles

## 背景
users 表 30 列、大多是认证不需的档案数据。
仅需认证数据的查询加载不必要列。

## 决定
拆为 users（认证: id、email、password）和 user_profiles
（档案: name、avatar、bio）。批量迁移避免锁表。
更新查询过渡期读两表。

## 后果
- 迁移 30 分钟但应用保持上
- 查询须更新 join 两表
- 回滚: 重合表（down 迁移中记录）
"""

// PR 描述链 ADR:
// "见 ADR: docs/adr/2024-01-15-split-users-table.md"

常见问题

• ⚠每 PR 结对审查——团队每周 15 小时审查会于本可 15 分钟异步审的 PR、过程变瓶颈。
• ⚠无文档结对审查——两开发者达决定但推理未写、下个触代码开发者不懂为何决定。
• ⚠结对审查变作者解释审查者点头——审查者不问难问题、设计问题不抓、会是讲座非审查。
• ⚠因"PR 小"跳高风险迁移结对审查——PR 50 行但删 100 查询依赖的列、异步审查未抓依赖。

最佳实践

• ✓高风险或设计重（迁移、认证、架构）的 5% PR 用结对审查、95% 用异步——结对抓设计问题、异步抓行问题。
• ✓结对审查决定记 ADR（架构决定记录）链 PR——推理为下开发者保非失于 Zoom 通话。
• ✓两参与者都应问问题和挑战设计——一人讲的结对审查是讲座非审查、设计问题不抓。
• ✓结对审查后异步审查跟进行级细节——结对抓设计、异步抓实现、两者都需。