上周在南京河西的一个研发工作室蹲点，刚进门就听见工位区拍键盘的声音。
不是部署出bug的问题。
是代码评审吵起来了。
写后端的小伙子把笔记本拍得响，说前端同事提的修改意见完全是没事找事——就一个参数的校验逻辑，至于翻出三年前的旧代码说事？
我凑过去看了眼屏幕，小伙子写的接口逻辑确实没硬错，跑测试也全过。但提意见的前端同事说，他上周刚接了这个接口的旧版本，参数边界值没做校验，线上漏过一次空指针，排查了三个小时。
说白了，双方都没全错。
麻烦在于，很多团队把代码评审的目标搞反了——不是要证明谁写的代码更牛，是要把那些藏在测试覆盖不到的地方的坑，提前刨出来。
没人愿意在下班前接评审
有次和一个做了八年后端的老工程师聊天，他说现在最怵的不是赶版本熬夜，是赶在下班前半小时收到的评审邀请。
谁都有累的时候。
盯着屏幕看了一下午业务逻辑，脑子已经转不动了，这时候拉你过来看几百行没见过的代码，你能提什么靠谱意见？
多半就是说两句”命名挺规范””逻辑没问题”，点个通过完事。
这种情况下走流程的评审，比不评审还糟。
因为所有人都觉得评审过了，代码就是安全的。等上线出了问题，回头翻评审记录，连当时是谁点的通过都记不清。
评审最忌讳的就是赶时间凑数。
我见过有团队专门把评审的时间卡在每周二周四的下午两点到三点，不卡下班点，也不刚吃完午饭犯困。每次评审最多过两个提交，多了就往后排。
就这么个小调整，线上因为低级错误出的故障少了快一半。
没有什么玄乎的方法论。
就是给大家留够看代码的时间。
被忽略的代码外信息
很多人觉得代码评审就是逐行看逻辑对不对，变量名起得好不好。
其实根本不是。
上次有个团队评审一段支付回调的逻辑，代码写得特别漂亮，抽了三层函数，命名也清晰，单测覆盖率百分之百。
结果一个做过支付的老产品多问了一句：”如果用户在回调请求发出的瞬间，刚好把订单退了，这段逻辑会重复给用户加余额吗？”
现场瞬间安静。
测试用例里根本没写这种极端时序的场景。单测再全，也覆盖不到人和系统交互的那些犄角旮旯。
说白了，代码评审是整个团队把各自踩过的坑，往同一段代码上叠的过程。
你踩过空指针的坑，你就盯着边界值看。
他踩过重复请求的坑，他就盯着幂等性看。
没人能把所有坑都踩遍。
但凑在一起，就能把大部分能想到的问题兜住。
我见过最离谱的评审，是一个团队把所有写代码的人拉成一个群，提交完代码直接把链接甩群里，谁有空谁看。
最后看了三天，提了两个关于注释格式的意见，就合并了。
结果上线当天，把本来要给用户发的优惠券金额，多打了个零。
损失倒是不大。但当时整个团队熬了半宿回滚、对账、给用户发短信解释。
事后复盘的时候，没人能说清当时评审的时候，到底是谁看了这段金额计算的逻辑。
这事没那么玄。
真正有用的评审，从来不是靠人多，是靠每个参与的人，真的对着代码问一句”这玩意儿跑起来会不会出问题”。
别把评审意见当人身攻击
我之前碰见过一个刚入职的小姑娘，第一次提交代码，被前辈提了二十多条意见，当场就掉眼泪了。
觉得自己写的代码被批得一无是处。
后来我跟那个提意见的前辈聊，他说他根本没觉得小姑娘写得差，就是他自己刚入行的时候，写的同类逻辑出过线上故障，所以看到类似的写法就忍不住多提两句。
很多团队的矛盾，就是从这里来的。
写代码的人觉得，你提这么多意见，就是觉得我菜。
提意见的人觉得，我好心帮你避坑，你怎么还不领情。
说白了，两边的立场没对齐。
评审意见针对的是代码，不是写代码的人。
你今天提的某个变量名太长、某个逻辑写得绕，不是说这个人能力不行，是说等三个月之后，其他人来读这段代码的时候，能不能少花点时间。
有个团队做过一个特别有意思的小规定。
所有评审意见，必须先写一句”这段代码哪部分写得不错”，再写要改的地方。
就这么个小规矩，团队里因为评审吵架的次数少了好多。
不是说要拍马屁。
是要让写代码的人知道，你不是来挑刺的，你是真的在认真看他写的东西。
上周再去那个河西的工作室，之前吵得拍键盘的两个小伙子，凑在一块看新提交的代码。
一个指着屏幕说，你这里加个超时重试啊，上次我写的同个接口，超时没重试，被运维追着骂了两天。
另一个挠挠头，说哦对，我忘了，这就改。
没有什么高大上的流程。
也没人把评审当成什么必须完成的KPI。
就是一群写过bug的人，凑在一起，尽量让新写的代码，少出点bug。