主审判断框架
主审判断框架
Section titled “主审判断框架”挑刺会自己膨胀
Section titled “挑刺会自己膨胀”评审者，尤其是对抗性的评审者，总想把评审写满。找不到严重问题时，就会把小毛病放大来填版面。如果一个评审者的 finding 全是小毛病和风格偏好，代码多半没问题。直接这么说。
假想的问题和真实的问题
Section titled “假想的问题和真实的问题”「要是有人在这里传了 null 怎么办？」只有调用方真的可能传 null，这才算一条 finding。去追调用点。如果输入在调用链更前面已经校验过，或者类型系统根本不允许，就驳回这条 finding。只看 diff 的评审者不一定看得到完整的调用链。你看得到。
过早抽象的建议
Section titled “过早抽象的建议”评审者常常建议抽函数、加接口、建抽象。这段代码会不会以第二种方式变化？不会的话，抽象就是过早的。能用的简单内联代码，胜过对眼下范围来说杀鸡用牛刀的漂亮抽象。
「换我会换种写法」
Section titled “「换我会换种写法」”这是代码评审里最常见的误报。一条 finding 说到底只是「我更喜欢另一种做法」，那它不是 bug，不是设计缺陷，也没什么可做的，除非评审者能指出当前做法的具体问题。驳回这类 finding，并说明理由。
缺少背景的迹象
Section titled “缺少背景的迹象”留意那些暴露出评审者没弄懂背景的 finding：
- 建议改作者既没写也没动过的代码
- 指出某种写法有问题，而它其实和代码库其余部分一致（评审者只是不知道）
- 推荐的做法和你知道的约束相冲突
这些是信息有限的评审者无心犯的错。客气地驳回就好。
评审者说对了的时候
Section titled “评审者说对了的时候”不要因为 finding 让人不舒服就驳回。对抗性评审的意义，就是抓住你会漏掉的东西。一条 finding 值得重视的迹象：
- 几个模型各自独立地指出了同一个问题（共识信号）
- finding 指出了一条具体的执行路径，而不是假想的情况
- finding 暴露了你对这段代码的心智模型里的缺口
- 你读完 finding，心里想「……嗯，还真是」
驳回安全问题和正确性 bug 时要格外小心。这类 finding 就算只有一个模型提出，也值得多查一查。