上周跟几个做后端的朋友撸串，有人吐槽说上次合了个PR，本来只是加个小接口，结果上线之后老服务的链路超时翻了三倍。翻代码才发现，新写的逻辑直接绕开了统一的缓存层，自己在本地开了个内存缓存。这事本质上就是代码评审中的架构一致性检查没做到位。
没人会对着架构文档逐行抠
很多团队的架构文档，写完就锁进wiki的深处，半年没人点开过。代码评审的时候，大家的注意力全在抠细节：变量名够不够规范，有没有空指针风险，单测覆盖率能不能凑到要求的线。没人抬一下头，看看这段新写的代码，是不是跟之前大家一起定的架构规则走。
之前接触过一个团队，定的明文规则是所有跨服务调用必须走统一的RPC封装层，不许直连下游的数据库或者服务实例。结果有个开发图快，在自己的服务里写了段直连订单库的查询逻辑。评审的时候三个资深工程师轮着看，全在说这个SQL写得不够优化，索引是不是建错了，没人注意到他根本没走规定的封装层。等后面要做全链路压测的时候，才发现这堆散在各个角落的直连调用，根本没法统一做熔断降级！
很多人觉得架构一致性是架构师的专属职责，跟普通评审没关系。说白了，那些写在文档里的架构规则，从来不是什么高高在上的设计理念，是之前踩过无数坑攒出来的代价。为什么规定不能直连数据库？因为之前散在各个服务里的直连逻辑，改个表字段要同步改七八个地方，漏一个就出线上事故。为什么要求所有日志必须走统一采集SDK？因为之前有人自己写逻辑把日志输出到本地文件，磁盘写满把服务搞挂的事，谁没见过？
别把检查做成了新的负担
不少团队一开始想推架构一致性检查，上来就整理个一百多条的规则列表，打印出来贴在评审会议室的墙上，要求评审的时候一条一条对着勾。结果呢？大家嫌麻烦，随便打个勾就过，规则写在那里形同虚设。麻烦在于，人的注意力是有限的，一次评审要扫几百行代码，你让他同时记一百条规则，根本不现实。
不如把最核心的核心架构红线拎出来，就三四条，贴在评审界面最显眼的位置。比如第一，有没有绕开统一的服务封装层？第二，有没有私自引入不在技术栈白名单里的依赖？第三，有没有修改不属于自己服务边界的逻辑？就这几条，多了根本记不住。
之前有个团队试过，把所有架构规则都做成了自动化检查插件，每次提交代码自动跑，违反规则直接标红。听起来很爽对吧？但代价是什么？插件的误报率高得离谱。比如规则说不能用本地缓存，但是有些兜底场景就是需要本地缓存做降级，插件不管这个，直接给你标违规，开发还要花半小时写豁免申请。搞了两个月，大家都开始想办法绕开插件的检查，反而没人真的去思考，这段代码是不是符合架构的整体方向。
正确的打开方式是让插件做自动化初筛，把明显违反规则的代码先标出来，但是最终的判断，还是要评审的人结合实际场景来定。不能让插件变成挡在人和代码之间的墙。
检查的本质是给架构留迭代的空间
很多人对架构一致性检查有误解，觉得这是为了捆住大家的手脚，不许创新。根本不是。这事没那么玄。你现在在评审的时候把一致性的问题卡住，本质上是给后面的人留够调整的空间。
举个最现实的例子，你现在放了一个绕开统一链路的代码进去，后面要做服务拆分、做单元化改造的时候，就得先花半个月时间把这堆散在外面的调用全部找出来，不然拆完就是一团理不清的乱麻。反过来，要是评审的时候就把这些问题挡住，后面架构要调整的时候，只要改统一的封装层就行，不用到处擦屁股。
我见过太多团队，架构文档写得天花乱坠，代码里全是野路子。等要做云原生改造的时候，光是理清楚各个服务之间的乱调用，就花了快半年时间，钱花了，人也熬垮了，回头才拍大腿，说当初怎么没在评审的时候把好关？
代码评审中的架构一致性检查，从来不是要揪着谁的错不放。看到不符合规则的代码，也不要上来就打回去重写。把规则背后的代价讲清楚：你这么写，后面维护的人要多花多少时间，上次我们因为类似的问题炸了三次线，你还记得不？大家都是一起干活的，没有谁想故意搞破坏，只是有时候忘了之前摔过的跤。
上周跟我撸串的那个朋友，回去之后把团队的评审模板改了，最上面加了三个必问的问题，就是那几条核心红线。现在过了快一个月，他说最近上线的线上故障率，降了快四成。
没什么花里胡哨的方法。就是在每次看代码的时候，多抬一次头，看看手里的代码，是不是跟大家一起搭的那套架子，对得上。