第一次做代码评审，我学到的三件事，墨迹

入职第三年，第一次以评审人的身份打开同事的合并请求。点开之前忽然意识到：以前都是别人看我，这次轮到我了。那天下午的评审做得磕磕绊绊，但有三件事当场就学会了。

先读测试，再读实现

一上来就读实现，很容易陷入对方的思路里，顺着他的逻辑走一遍，觉得哪里都对。先读测试，等于先看清楚这段代码承诺要做什么，再回头检查实现有没有兑现承诺。承诺和兑现之间的缝隙，就是问题所在。

第一版评审意见里我写了「这里写错了」，发出去之前改成「这里和上面的分支重复了，可以合并吗」。前者是审判，后者是提问。事实描述加一个问号，对方的反应会完全不同。后来同事说，那次评审他改得很舒服，我想一半功劳在这个问号。

不是每条意见都值得阻塞合并。命名不优雅但能看懂，可以提，但标注「不阻塞」；边界条件漏了一种输入，必须拦下来。把火力留给真正要紧的事，评审才有公信力。样样都拦，最后就样样拦不住。

这三件事没有一件是关于技术的，但我花了三年才明白：代码评审名义上评的是代码，实际上练的是沟通。