上周跟三个在互联网公司做后端的朋友在南京老门东边上撸串，烤筋刚端上来，其中一个人就开始骂。说这周组里的代码评审开了快三个小时，全是揪别人的变量名大小写不对、缩进少打两个空格，连个正经技术问题都没聊。结果上周上线的一个活动服务，绕开了统一的权限层直连用户数据库，出了越权查看订单的bug，查了整整两天才定位到。
没人愿意在评审里碰架构的真实原因
说实话，架构一致性这事，说起来虚。
不像代码逻辑写错了，跑个单测就能当场炸出来。它的代价要等三个月半年，服务堆得满到转不动、改个小需求要碰五六个模块的时候才显形。麻烦在于，你要是在评审会上揪着架构的事不放，很容易被当成没事找事。比如新人刚写了个模块，图快直接复用了隔壁组的老SDK，那个SDK是两年前给离线任务写的，根本不支持线上流量的熔断。你说他写错了？他单测全过，接口返回全对，代码风格也符合团队的规范。但就是不对。
很多团队的评审清单里，关于架构的条目全是空心的。什么“符合架构规范”，这种话写了等于没写。没人会在评审的时候逐行对照厚厚的架构文档，毕竟文档可能都是两年前的，连最近新拆的三个服务都没写进去。我上次去一个团队做交流，看见他们把架构规范打印出来贴在评审室的墙上，纸边都卷了，印的字都晒黄了，没人凑过去看过一眼。
把架构检查塞进评审流程的最小可行做法
这事没那么玄。
不需要你拉个十个人的架构委员会来卡每一行代码提交。说白了，只要把抽象的架构规则，拆成评审的时候一眼能看见的硬指标就行。
比如所有跨服务的调用必须走统一的网关层，这条就够硬。评审的时候你不用翻任何文档，就看提交的代码里有没有直连其他服务的IP或者内网地址，有就打回去。还有涉及核心数据写入的逻辑，必须放在对应领域的服务层，不能在订单服务里直接改用户表的余额数据。这些都是不需要高深架构能力，普通工程师在评审的时候扫一眼就能判断的事。
别搞什么复杂的评分系统。我见过最蠢的做法，给架构一致性打个1-5分，最后算个平均分。有啥用？打3分的代码，该上线还是上线，根本没人记得到底哪条逻辑是3分，过两周就全忘了。真正有用的，是把这些硬指标做成可被CI自动扫描的规则，提交代码的时候自动检查有没有直连数据库的配置、有没有用已经被废弃的SDK，扫到了直接把评审卡片的状态标红，评审人不用费脑子逐行翻找。
当然，也别觉得机器扫不到的就是没问题。上次有个提交，机器没扫出来违规，因为他把数据库连接串写在注释里绕开了静态检查脚本，评审的老工程师一眼看见注释里的连接串是核心用户库的，直接打回去了。这种机器覆盖不到的边角，才是评审里架构检查真正值钱的地方。
别把架构检查变成新的流程负担
说实话，很多团队一开始搞架构一致性检查，就容易走歪。
一开始定了十几条规则，评审的时候每条都要逐一核对，一个提交要拉五个人评，等半小时才能走完流程。最后大家嫌麻烦，干脆闭着眼把所有检查项勾完赶紧散会，又回到走流程的老路上。麻烦在于，架构一致性的检查，本质是拦那些会造成长期维护麻烦的错误，不是把所有代码都框死在一个僵化的模子里。比如你为了排查个临时的线上问题，在测试环境写了个小脚本直连数据库，这种根本不需要拦。要是连这种临时的调试代码都要走层层架构评审，那大家下次有啥问题都不会往正式的评审通道里提了，全私下改了偷偷上线，那才是真的乱。
之前跟一个做基础架构的工程师聊，他们团队的评审规则每季度会删三分之一。为啥？因为很多规则定的时候是为了解决当时的具体问题，等问题彻底解决了，规则就成了绑手绑脚的绳子。比如之前大家都喜欢把缓存逻辑写在业务代码里，出了好几次缓存击穿导致服务宕机的问题，就定了规则必须走统一的缓存组件。等半年后，所有业务工程师都用熟了这个统一组件，就不用每次评审都卡这条了，把精力腾出来查新冒出来的问题——比如最近大家开始随便用异步队列，把本该同步处理的支付回调逻辑全丢到队列里，导致用户等十分钟才收到支付成功的通知，这时候就把这条新的检查项加进去，把旧的、已经形成肌肉记忆的规则删掉。
说到底，代码评审从来不是为了挑谁的代码写得烂。大家坐在一起看提交的代码，本质是凑几个人的经验，把那些可能在几个月后爆雷的问题提前揪出来。代码评审中的架构一致性检查从来不是什么高大上的架构师专属工作，就是你在看别人代码的时候，多问一句“这个逻辑放在这，过半年我们改这块的时候，会不会找不着北”。
就够了。