小团队里的代码评审

小团队的代码评审很容易走向两个极端：要么变成形式上的“看过了”，要么变成逐行挑刺的消耗战。

先看意图

评审的第一步是确认作者想解决什么问题。如果从 diff 开始看，很容易把注意力放在命名和格式上，而错过方案本身的问题。

我们的做法是：提交说明里必须有一句“这样做是因为……”，评审先回应这句话。

再看待改动的边界

一个变更如果同时改了行为、结构和格式，评审者很难判断哪部分才是重点。拆成几个小提交之后，讨论会具体很多。

最后才是细节

格式问题交给工具。人只看工具判断不了的东西：命名是否表达了意图，错误处理是否完整，边界条件是否想清楚。

评审的目标不是让代码变得完美，而是让下一位维护者少一次猜测。