代码评审中的架构一致性检查 别等系统塌了才补窟窿
上周帮个做支付的朋友看他们的评审记录，翻到第三页就皱眉头。
他们组定的规矩是所有跨服务调用必须走统一网关，结果有个新提交的订单模块代码，直接写了个HTTP请求打到库存服务的内网IP上。
评审记录里全是说代码逻辑没问题、异常处理写得全、单测覆盖率够，没人提这茬。
等上线半个月库存服务扩容改了内网网段，订单直接挂了半小时。
这事没那么玄。
多数团队的架构检查都做偏了
很多团队现在的代码评审，全在抠代码风格、变量命名、有没有空指针。这些当然要管，但真正能把系统搞崩的，从来不是多写了个if else，是悄悄绕开了之前定好的架构边界。
有人说我搞个架构扫描脚本不就行了？把那些违规的调用直接拦在CI里。麻烦在于，脚本只能查你写进规则里的东西。比如你之前定了”所有支付回调必须走回调中心”，脚本可以拦直接写死的回调地址，但拦不住有人在回调中心里塞了个硬编码的第三方渠道密钥——这本质上也是架构一致性的问题，因为回调中心的职责就是做渠道路由、鉴权，不该存具体渠道的密钥。
我见过最离谱的团队，CI脚本拦到有个提交直接调了数据库，给打回来之后，开发把数据库连接字符串加密了下，脚本就认不出来了，照样把代码合进去了。
很多团队的wiki里放着三年前定的架构规则，没人更新，没人讲给新进来的人听，评审的时候谁要是按那个规则提意见，还会被老员工说”现在谁还看那玩意儿，早就不这么干了”。你说这一致性从何谈起？
上次跟个做中后台的技术负责人聊，他们之前把架构规则写在wiki里，评审的时候全靠评审人记忆去对，三个月下来攒了二十多个绕开规则的提交，有写定时任务直接连业务库的，有把缓存操作写在Controller层的，等要拆库的时候，光梳理这些违规点花了整整两周。
没人故意搞破坏。很多时候就是新人进来没人讲清楚为什么要定这些规则，评审的时候也没人逐一对，写代码的人觉得怎么快怎么来，看代码的人觉得逻辑没问题就过，最后技术债堆到拆不动。
评审时要查的一致性根本不是写死的清单
很多人觉得架构一致性检查就是对着checklist打勾，有没有用统一日志组件，有没有用统一异常处理，有没有走统一网关。这些是基础，但不是核心。真正要查的，是这段提交的代码，有没有偷偷改了之前所有人默认遵守的职责边界。
举个例子，你们之前定的商品模块只管商品信息的增删改查，不该处理库存扣减逻辑，那如果有人在商品的更新接口里，加了一行扣减库存的代码，哪怕他的代码写得再优雅，单测覆盖到100%，这也是架构一致性的问题。为什么？因为之前所有的库存操作都是走库存模块的，有统一的幂等校验、有操作日志、有库存预警，你在商品模块里直接扣，等于绕开了所有这些兜底逻辑，哪天出了库存对不上的问题，排查都找不到入口。
很多团队觉得在评审的时候花时间查这些，太耽误事。一个评审本来十分钟能看完，现在要翻之前的架构设计文档，要问这个代码为什么不按之前的边界写，要跟提交的人掰扯半天，效率太低。
但你算过账没有？现在花五分钟掰扯清楚，让他把扣库存的逻辑挪到库存模块，后续上线之后不用因为库存不一致赔给商户几十万，不用半夜爬起来排查三个小时的线上问题，不用等系统涨到几十个服务的时候，光梳理谁在偷偷跨模块调逻辑就花几个月。说真的，那些说架构检查耽误效率的团队，最后基本都在技术债上还了加倍的利息。
别把规则定成没人能遵守的死条款
很多团队搞架构一致性，一开始就想搞个大而全的规则体系，什么调用必须走网关、什么数据库操作必须走DAO层、什么前端组件必须用统一UI库，把规则写得密密麻麻，结果执行了半个月就没人看了。为什么？因为规则太死，没有给特殊场景留口子。
比如有时候某个第三方回调必须在某个服务里临时处理，走统一网关要多绕两跳，延迟高了满足不了实时性要求，这时候提交的人总不能为了守规则，把一个本来半小时能搞定的需求，拖成两周的网关改造吧？
那正确的做法是什么？评审的时候遇到这种绕开规则的提交，别直接打回。先问清楚原因。如果是真的有特殊场景，那就让提交的人在代码里加明确的注释，写清楚为什么要绕开规则，后续要跟进什么改造把这个口子补上。同时把这个例外情况同步给整个团队，让所有人都知道现在有这么个临时的例外，等后续改造完了再把这个口子堵上。
说白了，架构一致性从来不是要所有人死板遵守写在文档里的每一条规则，是要让所有人对”我们现在的系统边界是什么”有个统一的认知，别每个人写代码都按自己的想法来，最后拼出来一个谁都看不懂的四不像系统。
上周那个做支付的朋友，回去之后把他们的评审模板改了，加了一行必填项：”本次提交的代码有没有涉及跨模块职责调整、有没有绕开之前定好的架构边界”。就这一行，用了一个月，没再出现过直接打内网IP的提交。
没什么花架子。
代码评审本来就不是为了挑代码写得好不好看，是为了让大家一起把系统的底兜住。你现在在评审的时候多问一句，后面就少熬几个通宵。