上周跟几个做了五六年后端的老开发吃饭，酒过三巡聊到最烦的工作环节，一半人脱口而出代码评审。
有人说每次评审就像开公开批斗会，自己写的代码哪怕多打了一行没用的调试日志，都要被揪着说半小时。也有人翻个白眼说现在的评审全是走个过场，提交了PR随便拉个人点个批准就完事，半句话都没留。
别把评审当成给代码挑错别字
很多人对代码评审的认知还停留在找语法错、揪变量名、数缩进是不是对齐。
说白了，这些事现在静态检查工具半小时就能扫完一整个仓库，犯不着拉着七八个人开一小时会对着屏幕逐行念。
之前碰到个团队，花了两天把所有格式类的检查全配到了CI流水线里，只要有lint报错直接卡着不让进评审环节。剩下的评审时间，大家全在聊更值钱的事：这个模块的异常分支会不会在流量峰值的时候把数据库连接池占满，这个新写的缓存逻辑会不会跟三个月前留的那个兜底逻辑打架，这个接口的参数设计未来要加新字段的时候，会不会要打破老版本的兼容性。
当然要算代价。前期配规则、对齐团队习惯，确实要花点时间，甚至刚开始会有人觉得工具卡的太严，写个脚本都要折腾半天才能过检查。但这点投入，比开十次对着格式挑错的无效评审省的时间多太多。
评审里最容易被忽略的沉默成本
很多人算过一笔账，觉得评审是浪费时间。一个开发写了三天的功能，评审拉着两个同事各花半小时看，算下来光评审就耗了一个人半天的工作量，好像不如直接合进去上线来得快。
麻烦在于，你现在省的这半小时，迟早要在上线后的半夜被告警叫醒的时候连本带利还回来。
之前接触过一个做中小电商的团队，之前嫌评审麻烦，所有功能提交了直接合并发版。有次运营要上一个满减活动的逻辑，开发写的时候把满减的门槛判断写反了，满100减20的活动变成了满20减100，上线俩小时被用户薅走了十几万的优惠券，最后全团队连着熬了两个通宵才把账对完，把异常订单一个个处理完。
有人说那我上线前多测测不行吗？行啊。可测试同学的精力是有限的，他们要覆盖核心交易链路，要测各种端的兼容性，你写的那点边角逻辑，没人会盯着给你算满减的数值对不对。
代码评审是上线前最后一道防线。是跟你写代码的脑子同频的人，帮你跳出来看一眼。你盯着自己写的逻辑太久了，总会有盲区。谁写代码的时候没犯过把==写成=，把大于号写反的错啊？
别嘴硬。
好的评审从来不会把人骂哭
现在很多团队的评审氛围歪了。好像谁在评审里挑的错越狠，谁的技术水平就越高。
上次听个刚工作一年的小姑娘说，她第一次提交的PR，被工作十年的老开发追着评论”这代码写的像屎一样”。她当时坐在工位上眼泪都快掉下来，之后再也不敢主动提交自己的代码，能绕开评审的就绕开，最后出了线上问题大家还反过来怪她代码写的烂。
这事没那么玄。评审的本质是帮代码变更好，不是让写代码的人下不来台。你可以说这个逻辑这里有漏洞，下次遇到类似的场景可以怎么处理，没必要上来就人身攻击。
大家坐在这里的目标是一致的：别让有问题的代码跑到线上坑用户，也别让写代码的人因为一次评审就对写代码这件事产生阴影。
好的评审从来不是单向的批评。不是评审的人说什么就必须改什么。比如有时候你为了兼容某个老设备的特殊逻辑，写了点看起来绕的代码，你可以在评审的评论区把前因后果写清楚。大家讨论下来觉得值，就留着。觉得不值，就一起找更优的方案。没有谁是绝对正确的。
也别搞那种评审必须所有人都点头才能过的死规矩。一个核心的交易模块，拉着所有相关的开发、测试、产品都来看，是应该的。一个内部用的工具脚本，拉个经常用这个脚本的同事看一眼就够了，没必要搞全员评审的大阵仗，纯纯浪费时间。
太僵化的流程，最后一定会变成大家眼里的橡皮图章。反正不管写的怎么样，最后都是点个批准，那评审还有什么意义。
上周跟那个被骂哭的小姑娘聊天，她说现在换了个团队，评审的时候大家看到她写的有问题的地方，会笑着说这里要是这么改的话，后面排查问题会方便很多。她现在每次提交PR都敢在描述里写”这里我拿不准，大家多帮我看看”。
挺好的。
代码评审从来不是什么高大上的流程。就是一群写代码的人凑在一起，给未来要接你代码的人省点麻烦，给未来半夜被告警叫起来的自己少点骂声。