大泥球 (编程)
| 条目單純列出網址作為參考来源，缺乏更詳盡的資訊；一旦链接失效，將難以查证。 |
大泥球（Big ball of mud）是指一个缺少可认知架构的软件系统。这种系统往往是在业务压力、人员变动、软件熵增加等情况下开发所致。是一种反模式。
定义 编辑
Brian Foote与约瑟夫·约德的1997年的同名论文，给出定义如下：
所谓的大泥球就是一个随意结构化、蔓延的、不经心的、意大利面条式代码的乱七八糟混合。系统展现了无可争议的表象：不受管制的增长、重复、权宜之计的修补。信息被系统中相距很远的模块杂乱地共享，重要信息常变为全局的或者重复的。
系统总体架构可能从未良好定义。
其损害往往超过上述认知。稍有架构敏感性的程序员避开了这些泥潭。只有那些对架构不感兴趣的人，也许对修补这些失败的堤坝上的漏洞的日常琐事的惰性感到习惯的人，才愿意在这样的系统上工作。
Foote 与 Yoder认为Brian Marick最早提出了大泥球这个软件架构术语。[1]
根源 编辑
- 程序员在编写程序或是系统时遇到问题后的解决方法，往往缺少前期设计，不是合适的或者最优的解法，而是方便修改的，变动最小的、碎片式增长，这就为以后的系统架构的混乱甚至整个系统的崩溃埋下了隐患。
- 用户的需求或者编程的要求是在不断地变化的，应对需求和架构变化过晚，使得系统越来越复杂化，维护也越来越昂贵。
- 程序员的经验，技巧，眼界的限制。