代码评审中的架构一致性检查 别让架构约定沦为纸面规则

上次在南京1024开发者节的茶歇区，碰到个做电商中台的开发，攥着半杯冰美式吐槽。说他们组每周固定开三小时代码评审会，一半时间在争变量名该用驼峰还是下划线，另一半在抠方法嵌套层数有没有超过三层。没人提上次架构会拍板的“所有跨域调用必须走统一网关层”的规则，早就有人写了个RestTemplate绕过去。

多数代码评审根本没摸到架构一致性的边

很多人对架构一致性检查的理解，还停留在“有没有用公司指定的技术栈”——比如是不是用了团队封装的ORM组件，是不是接入了统一的监控SDK。这其实只是最表层的对齐。

真正的架构一致性，是代码写出来的实际运行逻辑，和当初画在架构图上的服务边界，能不能对得上。比如当初定的用户域和订单域不能直接读写对方的库，结果有人为了省一次跨服务调用，直接在订单服务里写了条SQL查用户表的手机号。这种问题，你光看代码风格根本查不出来。

那个吐槽的开发说，他们组之前出过一次线上故障。有人绕开网关直连了库存服务，后来大促流量涨了三倍，网关配的限流规则根本覆盖不到这条直连链路，直接把库存服务打挂了。事后复盘翻当时的评审记录，那段直连调用的代码，评审人当时只提了一句“这个方法写得有点长，拆一下”。半句话没碰架构边界的事。

靠人肉记规则的检查迟早会漏

很多团队的架构规则，都是当初架构组写在共享wiki里的。几十页的文档。谁会翻？

更麻烦的是，不少规则根本没形成书面文档，全靠老人口头传。新人进来的时候，前辈顺嘴提一句“跨域别直连”，过半年换了批人，传着传着规则就变味了。

真正能落地的架构一致性检查，从来不是靠评审人当场回忆规则，而是把规则提前拆成可校验的检查点，嵌到评审的固定流程里。

比如哪些点是必须核对的？跨域调用是不是走了团队统一封装的SDK，有没有直接写其他域的表的SQL，有没有把公共组件的逻辑硬编码到业务代码里，有没有把本该异步处理的链路改成同步阻塞。这些根本不需要你有多深厚的架构功底，只要把规则列成固定的checklist，评审的时候对着逐条勾就行。

有人会说这太机械，会把评审搞成走流程。但你仔细算算账，之前那些因为架构不一致踩的坑，哪个不是评审时多问一句就能拦住的？比如看到代码里直接new了个HttpClient发跨域请求，根本没走统一的网关SDK，这时候根本不需要争这个代码写得优不优雅，直接指出来违反了既定规则，让改了就行。省下来的精力，本来就该用来聊真正有价值的设计取舍。

别把架构一致性检查搞成架构组的专属权力

很多团队的误区是，架构一致性检查是架构师的事，普通开发评审时看到不符合规则的代码，也觉得“反正架构师会管”。

但现实是，架构师的时间根本覆盖不了每一行代码的评审。十几人的团队，每周几百个代码提交，就算架构师不写业务代码，也不可能把每个PR从头到尾抠一遍。

这事真没那么玄。架构一致性的维护，是每个写代码的人的责任。评审时看到有人绕开统一配置中心，直接把数据库连接串硬编码在代码里，你指出来让他改，这就是在做架构一致性检查。不需要你是资深架构师，只要你知道团队定的规则是什么，就有资格指出来。

之前见过个做云服务的团队，把最容易静态检查的架构规则，直接嵌到了代码提交的流水线里。比如只要代码里出现跨域直连的SQL，工具直接标红拦截，根本等不到人工评审才发现。当然，静态检查覆盖不了所有场景——比如你用了SDK但是传了不该传的参数，这种事还是得靠人工核对。但至少把最明显的违规问题提前拦下来，省下来的评审时间，再也不用耗在无意义的风格争论上。

上次在南京的技术沙龙上，碰到个做基础架构的朋友说，他们之前把代码评审六成的时间花在抠代码风格上，后来把风格检查全扔给格式化工具自动跑，把评审的固定流程改成先过架构一致性检查点，再看逻辑设计，最后才抠代码细节。现在每周评审时间直接砍了一半，线上因为架构不一致出的故障数，降了快七成。

别总说架构是虚的。你写的每一行代码，守不守当初和团队一起定的边界，就是架构最实在的落地。