大泥球 (編程)

大泥球(Big ball of mud)是指一個缺少可認知架構的軟件系統英語Software system。這種系統往往是在業務壓力、人員變動英語Turnover (employment)軟件熵英語Software entropy增加等情況下開發所致。是一種反模式

定義

編輯

Brian Foote與約瑟夫·約德英語Joseph Yoder (computer scientist)的1997年的同名論文,給出定義如下:

所謂的大泥球就是一個隨意結構化、蔓延的、不經心的、意大利麵條式代碼的亂七八糟混合。系統展現了無可爭議的表象:不受管制的增長、重複、權宜之計的修補。信息被系統中相距很遠的模塊雜亂地共享,重要信息常變為全局的或者重複的。

系統總體架構可能從未良好定義。

其損害往往超過上述認知。稍有架構敏感性的程式設計師避開了這些泥潭。只有那些對架構不感興趣的人,也許對修補這些失敗的堤壩上的漏洞的日常瑣事的惰性感到習慣的人,才願意在這樣的系統上工作。


Foote 與 Yoder認為Brian Marick最早提出了大泥球這個軟件架構術語。[1]

根源

編輯
  1. 程式設計師在編寫程序或是系統時遇到問題後的解決方法,往往缺少前期設計,不是合適的或者最優的解法,而是方便修改的,變動最小的、碎片式增長,這就為以後的系統架構的混亂甚至整個系統的崩潰埋下了隱患。
  2. 用戶的需求或者編程的要求是在不斷地變化的,應對需求和架構變化過晚,使得系統越來越複雜化,維護也越來越昂貴。
  3. 程式設計師的經驗,技巧,眼界的限制。

解決方法

編輯
  • 多種OOP指導方法,比如SOLIDGRASPKISS
  • 其他諸多年代久遠的、提倡高內聚、低耦合的方法一起出現。
  • 函數的第一規則是要短小,第二條規則是要更短小。[2]

參見

編輯

參考文獻

編輯
  1. ^ 存档副本. [2019-02-20]. (原始內容存檔於2019-02-20). 
  2. ^ 《代碼整潔之道》

外部連結

編輯