软技能系列第 5 章。代码评审大概是技术团队里「天天做、却几乎没人教」的事——多数人靠模仿前任的风格，要么太松（走过场），要么太冲（把 CR 变成战场）。这章把它当一门沟通手艺来讲。
先定基调：CR 的目标不是「挑错」，是「一起把代码变好」
评审里最伤人的不是「代码有问题」，是「你这个人有问题」的暗示。高质量 CR 有三个原则：
- 问题指向代码，不指向人：说「这里的状态处理有并发风险」，不说「你写的代码有问题」。
- 评论可执行：每条意见讲清「为什么」和「期望改成什么样」，而不是「感觉不对」。
- 记得肯定：真正好的地方值得一句「这个设计不错」——只提问题的评审人，最后会发现没人愿意被评。
评审看什么（按优先级，别眉毛胡子一把抓）
- 正确性与边界：并发、空值、异常路径、幂等——这是评审的核心价值，比风格重要一百倍。
- 可维护性：命名是否名实相符、职责是否清晰、三个月后新同学能不能读懂。
- 性能与安全：明显的 N+1、循环里发请求、SQL 注入/越权这类红线。
- 风格问题：交给工具（lint、格式化）解决，别在评审里争空格——把评审火力留给机器管不了的事。
心法：评审意见要分「必须改 / 建议改 / 可选」。必须改（正确性、安全）才坚持；建议改讨论；可选让作者决定。什么都坚持的评审人，会让作者连正确的代码都不敢写。
提意见的三个句式（带情绪归零）
- 疑问代替断言：「这里如果并发调用，状态会不会乱？」——让作者自己发现，比直接下结论更有效。
- 给上下文再给建议：「参考现有订单模块的做法，这里用幂等键会更稳」——意见带依据才有分量。
- 承认不确定性：「这块我不确定，建议加个边界测试验证一下」——真诚的不确定比假装权威更可信。
接意见的正确姿势（作者视角）
- 先理解，再反驳：收到意见先问「他为什么这么想」，七成意见背后是真实问题；两成是偏好，可以讨论；一成确实是他没看懂，解释清楚即可。
- 不要防御性拉满：「这是历史代码」「那边也这么写的」是 CR 里最没营养的回复。接得住批评的人，在团队里的可信度反而最高。
- 把「修改」当成学习信号：同一个人反复在并发上栽跟头，说明该补这块了，而不是「他总针对我」。
让 CR 流程真正跑起来的配套
- 小 PR 是 CR 的生命线：500 行以内的 diff 才有高质量评审的可能，5000 行的 PR 等于没人评审。
- CR 要进发布流程：不评审不合入，而不是「有空评一下」。
- 新人保护期：新同学的 PR 先在组内过一遍再发全组，别让第一次 CR 变成劝退现场。
落地清单
- 意见分三档：必须改/建议改/可选
- 问题指向代码，评论可执行
- 用疑问句式让作者自己发现问题
- 值得肯定的地方说出口
- PR 控制在可评审的规模
相关：跨团队协作 ｜ 故障沟通与复盘不甩锅（软技能系列后续）