这事说起来真的窝火。
很多团队的代码评审，到现在还停留在“找代码bug”的层面，对藏在代码里的架构偏差，连个基本的检查意识都没有。
别等系统散架了才想起查架构一致性
说白了，代码评审中的架构一致性检查，从来不是要求你把几十页架构文档背得滚瓜烂熟，而是要判断眼前这几行代码，是不是和团队已经达成共识的分层逻辑、依赖方向、服务边界对着干。
很多人觉得架构文档是架构师的事，我写业务代码，能跑就行。
真不是。
你现在图方便，在Controller层直接写SQL，下次新人进来跟着学，不出半年，整个项目的分层就成了四不像。到时候改个用户信息的需求，要在五个不同的层里同步动逻辑，哭都来不及。
我之前接触过一个做电商的团队，最开始就是没人在评审的时候盯架构一致性，两年下来，订单服务里嵌了三分之一的库存逻辑，库存服务里又混了支付的回调逻辑，最后想做个库存系统的拆分，光梳理依赖关系就花了四个月。这成本，早就在每一次漏过架构检查的评审里，悄悄攒下来了。
最容易被漏掉的几个检查细节
别觉得架构一致性检查是很虚的事，要查的点都很具体。
首先是依赖方向。本来团队早就定好，公共基础层是最底层，绝对不能依赖上层的业务模块，结果有人为了少写个状态枚举，直接在基础层里引了订单模块的类。这种问题，单元测试测不出来，代码扫描也不一定能抓全，等上线之后，只要订单模块改个枚举值，所有依赖基础层的服务全跟着崩。
还有服务边界的判断。本来两个服务的职责划得清清楚楚，一个管用户，一个管内容，结果有人为了省一次跨服务调用的开销，直接在用户服务里写了个拉取内容列表的逻辑。时间长了，当初拆服务的意义就全没了，哪个服务都不敢随便重启，生怕影响到别的链路。
哦对，还有中间件的使用约定。比如团队早就定了，非核心链路的缓存必须设过期时间，非核心的消息必须走死信队列做兜底，结果有人写代码图省事，给热点数据的缓存设了个永久有效，高峰期一到，缓存占满了整个内存，服务直接OOM。这种代码本身没有语法错，逻辑也对，就是和之前定的架构规则不一致，出了问题往往最难排查。
检查的时候别搞成上纲上线
我见过最离谱的团队，评审的时候为了一个变量的命名风格吵四十分钟，却对代码里跨层调用的问题视若无睹。这种评审，开了还不如不开。
做架构一致性检查，最怕走极端。要么完全不管，等系统烂透了才想着重构；要么把规则卡死，只要代码和文档对不上，不管什么原因直接打回。这两种都不对。
说实话，架构规则本身不是刻在石头上的。业务在变，团队在变，当初定的规则可能本来就有不适用的场景。比如某次大促前的紧急需求，为了赶上线时间，临时做了个架构上的妥协，这时候评审的时候，要做的不是硬卡规则把需求打回，而是要明确记下来：这个临时改动的边界是什么，后续哪个迭代要把技术债还上，不能让这种临时的权宜之计，变成长期挂在系统里的烂账。
麻烦在于，很多团队把架构一致性检查搞成了“证明你错了”的权力游戏，评审人拿着文档当尚方宝剑，不管实际场景，只要不符合就打回。最后开发团队为了不被卡，只会变着法绕开规则，反而让架构更乱。
其实现在很多通用的检查规则，根本不需要靠人来盯。比如依赖方向不对，把规则写到CI的静态检查插件里，代码提交的时候直接报错，根本等不到人工评审的环节。剩下那些需要结合业务场景判断的内容，比如临时的架构妥协合不合理，后续的技术债怎么还，再放到评审会上大家一起聊。这样大家的精力才不会浪费在抠细枝末节上，真正把检查的价值落到实处。
上次那个线上故障排查完之后，那个团队花了两周时间，把所有核心链路的代码重新过了一遍，把之前漏过的架构不一致的点全列出来，排了个优先级逐个改。改完之后，后续的需求开发速度反而快了近三分之一——之前大家要在各个乱七八糟的调用逻辑里翻半天，现在链路顺了，写代码自然不用绕弯。