我在上一家公司经历过一次让我记到现在的代码审查。那是我第一次负责推送服务重构，写了大概两千行，自信满满地提了MR。结果第二天醒来，评论区挂了四十多条评论，大部分是“这个命名不行”“这里为什么不用xxx模式”“逻辑太绕了”。我当时觉得天都要塌了，一个一个回，改到凌晨三点。后来我冷静下来一个一个看那些评论，发现有一半以上的人根本没看完整实现，他们是看到某个函数就随手点评。最讽刺的是，有个高级工程师盯着我某个工具类说“这里应该用Optional避免空指针”，但其实那个类里我明确写了注释，说明这个字段在业务上不允许为空，而且整个团队上个季度才决定不滥用Optional。没人记得这个决定，也没人看注释。那天的审查，本质上是一群人在对着截图表演专业。
后来我去了另一家公司，这家公司的代码审查又是另一个极端。他们讲究“团队和谐”，审查基本是走过场，只要不红脸就通过。评论永远是一两个“LGTM”，或者偶尔有人发个“建议提取方法，非阻塞”。看上去效率很高，但我知道有很多垃圾代码就是这么合进去的。有一次线上事故，就是有人把生产环境的配置密钥硬编码到了配置文件里，而代码审查时大家只看了业务逻辑。没人检查配置相关的改动。你可以说我倒霉，但这事真的让我开始怀疑：代码审查到底是为了质量，还是为了让大家觉得我们在关心质量。
我现在越想越觉得，代码审查在大多数团队里已经变成一种仪式。它存在的意义不是发现问题，而是出了问题时可以分锅。你看那些审查严格的团队，他们不是没有吵架，但吵完依然会有漏网之鱼；审查宽松的团队，大家都忙着赶版本，审查只是流程里的一个勾。真正的难点在于，代码审查的“上下文”是完全断裂的。审查者看到的是diff，是几行代码的增删，但看不到写代码的人当时面临的约束、跟产品经理的争论、凌晨三点修的bug。你在这种信息不对称之下做评论，基本等于隔空猜谜。这不是人的问题，是机制的问题。
我并不是说要放弃代码审查，而是说要重新设计它的形态。我试过一些办法，比如把大MR拆成小步提交，每次改动尽量控制在几十行以内；比如要求提交说明里必须写清楚背景和取舍，而不只是“修复bug”；比如指定“负责审查的人”而不是一群人围观。这些方法确实有效，但最重要的可能不是这些。我觉得最核心的是：每个参与审查的人都要强行提醒自己——我不了解全部上下文，我提出的其实不是“问题”，而是“疑问”。一旦你放下“我是在帮你找茬”的心态，评论的语气就会完全变掉。另一方面，写代码的人也要学会在提交说明里暴露自己的不确定，而不是把代码包装得无懈可击。我们越是想让对方挑不出错，审查就越容易变成面子工程。
现在我做技术管理，但我还是会在review别人代码的时候忍不住说出“这段我感觉不对”这类话。我也还是会被别人指出低级漏洞。我慢慢接受了一个事实：代码审查永远不会完美，它只是一种让人被迫看别人代码的机制。如果它能让我们偶尔发现一个真实的问题，那已经很值了。但如果它只是让我们互相表演，那不如把时间省下来，一起去喝杯咖啡，聊聊上下文。
