大泥球 (編程)
| 條目單純列出網址作為參考來源，缺乏更詳盡的資訊；一旦連結失效，將難以查證。 |
大泥球（Big ball of mud）是指一個缺少可認知架構的軟件系統。這種系統往往是在業務壓力、人員變動、軟件熵增加等情況下開發所致。是一種反模式。
定義 編輯
Brian Foote與約瑟夫·約德的1997年的同名論文，給出定義如下：
所謂的大泥球就是一個隨意結構化、蔓延的、不經心的、意大利麵條式代碼的亂七八糟混合。系統展現了無可爭議的表象：不受管制的增長、重複、權宜之計的修補。信息被系統中相距很遠的模塊雜亂地共享，重要信息常變為全局的或者重複的。
系統總體架構可能從未良好定義。
其損害往往超過上述認知。稍有架構敏感性的程序員避開了這些泥潭。只有那些對架構不感興趣的人，也許對修補這些失敗的堤壩上的漏洞的日常瑣事的惰性感到習慣的人，才願意在這樣的系統上工作。
Foote 與 Yoder認為Brian Marick最早提出了大泥球這個軟件架構術語。[1]
根源 編輯
- 程序員在編寫程序或是系統時遇到問題後的解決方法，往往缺少前期設計，不是合適的或者最優的解法，而是方便修改的，變動最小的、碎片式增長，這就為以後的系統架構的混亂甚至整個系統的崩潰埋下了隱患。
- 用戶的需求或者編程的要求是在不斷地變化的，應對需求和架構變化過晚，使得系統越來越複雜化，維護也越來越昂貴。
- 程序員的經驗，技巧，眼界的限制。