反馈技巧

这一课你将能做到

1. 写出「对事不对人」的建设性 review 评论，降低作者防御心理
2. 区分「必须修改」「建议修改」「仅供参考」三种反馈强度
3. 处理 reviewer 和作者之间的分歧，避免 PR 陷入僵局

为什么要学

Code Review 最大的成本不是时间，是人际关系成本。一句「这写的什么」可能让作者三天不想提交代码；一句「这里如果这样改会更好，因为...」能让作者心甘情愿改完还感谢你。

人话：Review 的目的是让代码变好，不是证明你比作者强。表达方式决定你的意见会不会被采纳。

先建立图像

反馈的三层强度

P0 - 阻断（Must Fix）
└─ 「这里存在 SQL 注入风险，攻击者可以通过 keyword 参数
    注入恶意 SQL。必须改为参数化查询。」
    → 不修改不能合并

P1 - 强烈建议（Should Fix）
└─ 「这个函数 80 行，包含 3 个职责，建议拆分为
    validateOrder / buildOrder / saveOrder 三个函数，
    可读性和可测试性都会提升。」
    → 建议修改，但可协商

P2 - 仅供参考（Nit / Optional）
└─ 「nit: 变量名 `list` 太泛了，改成 `courseList` 更明确。
    不改也行，看个人习惯。」
    → 可改可不改

标记强度能让作者快速判断优先级，避免在 P2 上浪费时间。

跟着做

步骤 1：用「提问」代替「断言」

❌ 反例：

这个实现是错的。
这样写性能很差。
你不应该这么设计。

✅ 正例：

如果两个用户同时调用这个方法，会不会都通过校验导致超卖？
我印象中这种写法在数据量大的情况下会有性能问题，
你有没有做过 benchmark 验证？
这个设计和现有模块的风格不太一致，是出于什么考虑？

为什么有效：提问让作者自己发现问题，比被告知「你错了」更容易接受。即使作者最后证明你错了，他也不会觉得被冒犯。

步骤 2：给理由，不给命令

❌ 反例：

改成用 Optional。
把这个拆成两个函数。
不要用这种方式。

✅ 正例：

建议用 Optional 包装返回值，因为调用方目前需要处理
null 的情况，用 Optional 可以强制调用方显式处理空值，
避免遗漏。

这个函数目前做了「校验 + 计算 + 持久化」三件事，
建议拆分为三个函数，这样每个函数可以独立测试，
后续修改时影响面也更小。

公式：建议 + 理由 +（可选）示例代码。

步骤 3：标记反馈强度

❌ 反例：所有评论混在一起，作者不知道哪些必须改

1. 这里有空指针风险
2. 变量名可以更好
3. 建议添加缓存
4. 这里逻辑不对

✅ 正例：明确分级

[blocker] 第 45 行存在空指针风险，当 course 为 null 时会 NPE。
          必须修复。

[suggestion] 变量名 `list` 建议改为 `courseList`，更明确。
             不改也行，看团队习惯。

[question] 这里每次查询都新建 Redis 连接，是出于什么考虑？
           如果是担心连接池问题，我们可以用 Lettuce 的连接池。

[nit] 这个注释是多余的，代码本身已经很清晰了。

常用标签：

• [blocker] / [must]：不修复不能合并
• [suggestion] / [should]：强烈建议修复
• [question]：需要作者解释
• [nit] / [optional]：吹毛求疵，可改可不改