代码评审中的架构一致性检查藏在CR细节里的隐形炸弹
2026-11-02 12:16:17
作者：
fawen
上周帮朋友排查线上故障，翻了3个迭代的CR记录，愣是没找到有人拦的点——新加的支付回调逻辑直接写在订单服务的 controller 层，绕过了之前约定的统一资金校验切面。
故障不大，就是多给用户退了两笔款，前后折腾了6个小时才把账对平。
没人故意写烂代码。就是大家在CR的时候，都自动跳过了架构层面的核对，只盯着几行代码的语法、变量名、测试覆盖率看。
没人愿意在CR里做架构检查
这事没那么玄。
大部分团队的CR checklist 列得比外卖菜单还长：变量名规范？注释够不够？有没有写单元测试？翻来覆去都是这些不用动脑子的事。架构一致性？谁爱查谁查。
麻烦在于，架构约束是个“没用”的东西——你没做，当下跑的好好的，没人给你发奖金；你做了，万一哪天出线上问题，反而要被人说“当初为啥要拦我这个需求？耽误了多少进度？”
CR会议上架构一致性核对白板实拍
大家都算得清这笔账。多一事不如少一事，对着代码风格挑点不痛不痒的问题，交差了事，何必揪着架构层面的偏差得罪人？
别把架构检查当找茬
别把架构检查当找茬
很多开发对架构检查的抵触，本质是把这个事和“挑代码错别字”划等号了。
说白了，代码评审中的架构一致性检查拦的根本不是你写的代码好不好看，是你有没有动不该动的层。比如团队约定所有跨服务调用必须走统一的网关客户端，你非要自己写个RestTemplate直接调下游，短期看省了3行代码，等下游服务要改鉴权规则的时候，你就得挨个找这些散落在各个服务里的硬编码调用点。
我之前见过一个团队，为了赶大促需求，把库存扣减逻辑直接写在了营销活动的服务里，绕过了统一的库存锁机制，大促当天超卖了1200多单，事后回滚查代码，发现这个提交过了3轮CR，没人提一句“你这逻辑放错服务了”。
架构层面的偏差，从来不会在提交的当天就爆雷。它会像埋在代码里的小石子，等你走了几十公里之后，才会把你绊倒。
没人想当坏人。CR的时候大家都忙着赶进度，对着几行代码的风格品头论足半小时，真碰到架构层面的偏差，反而没人敢开口——万一这个提交是组里资历最老的人写的？万一提了意见被打回来，要多改两天？
把检查规则钉在代码提交流里
这事靠人自觉没用。你总不能在每个CR评论区都蹲个架构师，天天盯着谁写的代码越界，碰到点偏差就跳出来说“你这不符合架构规范”，先不说架构师有没有那么多时间，光是这种随时随地被挑错的感觉，就足够让大部分人产生抵触情绪。
最落地的办法从来不是搞培训、开宣贯会，是把架构约束拆成可执行的机器规则。比如约定所有数据访问层的代码必须放在dao包下，你就写个简单的静态检查规则，只要controller层出现了直接的数据库连接调用，直接在提交的时候给你打回，根本不给人留人情的空间。
代码仓库架构约束规则配置界面截图
有人说，这样会不会太僵化？比如碰到特殊场景要临时绕一下怎么办？
简单。规则留白名单通道，你要申请绕规则，必须在提交的时候填清楚原因，同步给整个架构组留痕——不是不让你灵活，是你灵活的代价，要所有人都看得见，别等出了问题大家一起背锅。
我见过太多团队，把架构文档写的像教科书。
没人看。真的。
你把文档存在云文档里，权限开的再高，不如把规则嵌到提交检查里，让开发在写代码的时候就知道，哪些地方碰不得。
说实话，代码评审里最不值钱的意见，就是“你这个变量名起的不好”。最值钱的意见，是你看完整个提交的逻辑，说一句“这个功能应该放在另一个服务里，不然三个月后你自己都找不到这段代码在哪”。
别等线上炸了才想起补架构检查。那些你在CR里放过的小偏差，最后都会变成半夜叫你起来改bug的坑。
免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。如有侵权请联系删除。
文章名称：
代码评审中的架构一致性检查藏在CR细节里的隐形炸弹
文章链接：https://m.itcdj.com/it/394.html