什么是大泥球反模式
大泥球（Big Ball of Mud）由 Brian Foote 与 Joseph Yoder 在 1997 年提出，描述缺乏清晰架构的系统形态：边界模糊、依赖纠缠、补丁层层叠加，短期能跑但修改风险随规模上升。识别信号很直接——改一处牵连多处，没有人能说清完整的调用关系。
基本信息
| 成因 | 持续赶工、缺少边界约束、评审缺失、人员流动 |
|---|---|
| 典型症状 | 循环依赖、复制粘贴、全局变量、测试难以编写 |
| 危害 | 变更风险与成本随规模非线性上升，故障定位困难 |
| 应对方向 | 先加护栏与测试，再用绞杀者模式渐进改造，不做一次性大重构 |
典型使用场景
- 遗留系统接手：先做依赖地图与热点分析，摸清真实结构
- 改造立项：评估哪些模块相对独立可作为首批拆分试点
- 护栏建设：加静态依赖检查与自动化测试，先阻止新增循环依赖
- 故障排查：用调用链与依赖图定位改动牵连范围
- 技术债治理：把结构债单独登记，按利息排序偿还
- 外包交接：以依赖地图与接口清单作为交接基础
诊断与护栏（示意）
诊断与护栏（示意）
# 1) 生成依赖图，找出循环依赖与高扇入模块
madge --circular --extensions ts src/ # 循环依赖清单
depcruise --output-type dot src/ | dot -Tsvg > deps.svg # 依赖可视化
# 2) 加护栏：把当前违规设为基线，只拦新增
# （避免历史违规导致检查永远红灯，团队很快关闭检查）
# 3) 选试点：挑耦合最低、业务相对稳定的模块先划边界
# 4) 小步替换：用绞杀者把模块迁入新边界，每次替换后回归验证改造路径与判定
| 阶段 | 动作 | 完成判定 |
|---|---|---|
| 护栏 | 加测试与静态依赖检查，设定违规基线 | 新增违规为零 |
| 试点 | 选低耦合模块先明确接口边界 | 接口稳定，替换后可回滚 |
| 替换 | 用绞杀者逐块迁入新边界 | 旧路径流量归零并清理 |
| 记录 | 维护依赖地图与违规趋势 | 违规数量持续下降 |
不要在泥球上直接做大范围重构：先加自动化测试与边界约束，再逐步替换，否则一次改动就可能引发连锁故障。
泥球往往是理性选择的结果而非懒惰：在交付压力下，打补丁的短期收益确实更高，所以治理要给团队可用的替代路径。