四个人的团队，代码评审只留三道关

周三下午，我的待评审列表里躺着六个 PR，最大那个 1214 行 diff，标题写着「修复登录问题并优化用户模块」。我滚了两分钟，拉到最底下点了 Approve。

那天晚上我有点不安。不是因为那个 PR 出了事故——它没出——而是因为我意识到，我们的评审已经变成了一种仪式：大家都忙，但流程要求有个人点一下，于是就有个人点一下。

后来我们四个人花了一个下午，把这件事重新定了一遍。原则只有一条：评审只处理机器处理不了的分歧。

先把机器能干的活挪走

最早我们把格式、命名、import 顺序这些东西写进一份「评审注意事项」。结果是没人看，然后每次评审还是有人留一句「这里少个空行」。

现在我们把这些直接做成提交前钩子，装不上就提交不了：

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.6.9
    hooks:
      - id: ruff
        args: [--fix]
      - id: ruff-format
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer

类型检查和测试放在 CI 里，红灯的 PR 不给评审。这一步省下的不是时间，是注意力——人一旦在评审里看过三个空格问题，第四个真问题他也会当成噪音。

我给自己定了个判断标准：同一条评审意见如果我已经说过第二遍，它就不该由人来说第三遍。 我们有一条「禁止在日志里打手机号」的规矩，讲了两次还有人犯，后来改成 CI 里一条 grep 检查，世界安静了。

三百行是一条线

我自己的阈值大致是这样：两百行以内，我能逐行看；三百到六百行，我开始跳读，只看结构；超过八百行，我基本是在看标题和文件名猜意图。这个数字不精确，但顺序不会错——评审质量和 diff 行数是反比。

拆不动的时候，通常是这个改动本身混了两件事：重构和功能。我们的做法是先提一个「不改行为」的重构 PR，合并之后再提功能 PR。判断「不改行为」有个粗暴办法：这个 PR 合并后，现有测试的断言需不需要改。需要改，说明行为变了，别混在一起。

加一条：PR 描述里必须能用一句话说清「改了什么、为什么」。说不清的那个 PR，通常作者自己也没想清。

谁看、看什么、什么时候回

模块 owner 必看，因为只有他知道这块代码底下的地雷。再加一个人：不熟悉这块代码的人。他代表三个月后的你——如果他在 PR 描述里找不到「为什么这么改」的答案，那就是描述写漏了，不是他理解能力差。

四个人的团队，最糟的做法是把所有人都指派上去。后果是每个人都以为别人看了。

关注点是有顺序的：正确性 → 错误处理和边界 → 可读性 → 风格（已交给机器）。明确不看的东西也要说清楚：作者的个人偏好、半年后可能才有的需求、以及「如果是我我会怎么写」。最后这条最难克制，我自己经常犯。

评论我们用前缀区分：

[必须] 这里并发写同一个 key，会丢更新。
[建议] 这个函数可以拆一下，但我也不确定值不值。
[疑问] 为什么这里要重试三次而不是两次？

作者只需要回 [必须]，其余可以只回一句「记下了」。没有前缀的评论最耗人，因为谁也不知道要不要改。

时延上我们约定：工作日当天给第一个反馈，看不了也要回一句「今天看不了，明早看」。这条比任何评审规范都管用——大部分评审拖延不是因为没时间，是因为对方不知道你在等。

还有一条容易被忽略：合并权在作者手里。 评审者点 Approve 的意思是「我没发现问题」，不是「我批准了」。按钮由作者自己点，责任也就自然落在他那儿。

有些分歧不该在评论里解决

如果一个 PR 让你想推翻整体设计，那不该在评论区来回打字。评论适合指出问题，不适合讨论方向。我们的临时约定是：同一个 PR 里争论超过三轮，就停下来约个十五分钟的语音，把结论写回 PR 描述。

我还没有定论的是要不要度量评审。我会看两个东西：评审之后是否还需要二次改动，以及同一个问题是否重复出现。但我没把它们做成看板，也没排名——一旦排名，大家会开始数评论条数，那是个坏指标，我自己就会为了数字好看去挑软柿子。

那天最后，我把那个 1214 行的 PR 打回去了，让它拆成三个：一个纯重命名，一个抽函数，一个真正的登录修复。作者不太高兴。但在第二个 PR 里，他自己发现有个边界情况之前一直没处理。

我现在打开评审列表的第一件事，是看 diff 行数，而不是看标题。