审查礼仪

及时审查、优雅回应反馈、保持审查聚焦代码非人。

为什么

代码审查既是技术也是社交过程，礼仪定是协作改进还是对立战。最常见礼仪失败是延迟——PR 放 3 天因审查者"忙"、作者阻、功能滑、团队速度降。第二是防御——审查者留评论、作者争而非考虑、审查变赢辩论非解问题。第三是个人化——"你总写这 bug"使作者防御而"这模式有 bug"保持聚焦代码。好礼仪非关于好；关于有效——及时、聚焦和尊重的审查更快产更好代码，因反馈被收和行动而非辩论和延迟。

何时使用

每审查交互——请求审查时、审查时、回应反馈时、批准或请求变更时。

如何做

1. 及时审查（4-24 小时内）
   - 放 3 天的 PR 阻作者慢团队
   - 若今天不能审查，说并建议另一审查者
   - 小 PR（< 200 行）应同天审查

2. 保持 PR 小且聚焦
   - 每功能或修复一 PR 非杂物变更
   - 目标 < 400 行——大 PR 不能彻底审查
   - 若 PR 大，请作者拆

3. 优雅回应反馈
   - 谢审查者抓 bug——他们刚救你于生产问题
   - 若不同意，用证据解释非情绪
   - 若审查者错，友善教——"实际这安全因..."
   - 不为赢争——为找对答案争

4. 保持评论聚焦代码
   - 评代码非作者: "这函数太长"非"你写长函数"
   - 用"我们"建议: "我们可提取为 helper"非"你应提取"
   - 避"总"和"永不"——听起来控且通常错

5. 代码够好时批准
   - 不因 nit 阻——批准留 nit 为非阻评论
   - 完美是好的敌人——带 nit 合并的 PR 比阻的 PR 好
   - 若代码正确、安全且测试了，批准

示例

// 请求审查（作者礼仪）:
// PR 描述:
"""
## 什么
为用户注册端点加输入验证。

## 为什么
当前端点接受任何字符串为邮箱，非有效邮箱时致数据库错误。

## 如何
插入数据库前用 zod 验证邮箱格式。

## 测试
- 加了有效和无效邮箱单元测试
- 手动测 API: POST /register { email: "非邮箱" }

## 清单
- [x] 加测试
- [x] 无破坏变更
"""

// 及时审查（审查者礼仪）:
// - 小 PR 4 小时内审、大 PR 24 小时内
// - 若今天不能审: "今天不能审，能问 @teammate 吗？"
// - 不让 PR 静默放 3 天

// 回应反馈（作者礼仪）:
// 审查者: "18 行: 邮箱为空字符串时怎样？"
// 坏回应: "不会，前端验证了。"
// 好回应: "好抓。我加最小长度检查:
//   z.string().email().min(1)。也加空字符串测试。"

// 审查者: "考虑此处用事务。"
// 坏回应: "没事，操作独立。"
// 好回应: "你对，若第二个插入失败第一个已提交。我包两在事务中。"

// 保持评论聚焦（审查者礼仪）:
// 坏: "你总忘处理错误情况。"
// 好: "此处错误情况未处理。数据库不可用时该怎样？"

// 坏: "这函数太长，你应拆。"
// 好: "这函数 80 行处理三个关注（验证、数据库、邮件）。
//   能否拆为三个小函数提高可读性？"

常见问题

⚠因审查者"忙"让 PR 放数天——作者阻、功能滑、团队学审查是瓶颈，停开 PR 累积未审查变更。
⚠每评论争而非考虑反馈——审查者花 30 分钟辩护代码、审查花一周、团队避审那人 PR。
⚠因 nit（变量命名、导入顺序）阻 PR——作者不能合并正确、测试、安全变更因风格偏好，审查过程变瓶颈。
⚠不实际审查批准——审查者点"批准"为好或避冲突、bug 发、审查无价值。

最佳实践

✓24 小时内审查（小 PR 同天）——及时审查保持作者不阻团队速度高，显尊重作者时间。
✓保持 PR 小（< 400 行）聚焦一变更——小 PR 15 分钟彻底审、大 PR 得漏 bug 的肤浅略读。
✓以谢和证据回应反馈非防御——审查者抓 bug、谢他们；若不同意用测试或参考解释非争论。
✓代码正确、安全且测试时批准，留 nit 为非阻评论——完美是好的敌人，带 nit 合并的 PR 比阻功能好。