Big Ball of Mud（大きな泥だんご）は、でたらめに構築され、乱雑で無秩序、ダクトテープで繋ぎ合わされたようなコードのジャングルのことである。何年にもわたって、この泥を扱うための年月をかけて考えられた凝集性の高く結合度の低い種々のガイドライン、例えばSOLID、GRASP、KISSなど、を紹介してきた。しかしながら、その状況は厳しく、Big Ball of Mud はいまだソフトウェアを設計し構築する最もポピュラーな方法のままである。
Dave Nicolette氏はJavaで記述された次のような一片のコードを最近見つけたという。
public Thing getThing(Integer id) {
return new Beta().getGamma().getDelta().getEpsilon().getOmega().getThing(id);
}
このコードは次のような複数のコードの臭いに苦しんでいる。
- メッセージチェーン – 欲しい物を得るための呼出が6層の深さにまでなっている
- 不適切なまでの蜜な関係 – クライアントは欲しい物を得るために他のクラスの内部構造について知る必要がある
- みだらな露出 – beta、gamma、delta など直接関係のないオブジェクトを無意味に露出させている
Daveによれば, 以下のようになことが言えるという。
あるテーマに対して利用可能な情報の豊富さにもかかわらず、生計を立てるためにソフトウェアを書いている大多数の人たちはどちらかにあてはまる。
(a) 健全なソフトウェア設計のためのいかなるガイドラインをまったく知らない、または
(b) そのガイドラインを大きく誤解している。
同様に、Brian Foote氏 と Joseph Yoder氏による Agile 2009 でのセッションの経験をFJ氏は回想している。
泥が発生する理由は大抵の場合、以下のいずれかに絞り込まれる。
- 使い捨てのコード
- 段階的な成長
- 働かせ続けること
- コピーペーストによる転移（間違いだらけのコードが多くの場所で再生産され、広がること）
興味深いことに、FJ氏によれば、Yoder氏はAgileの多くの側面が直接泥を産んでいると感じている。これらには以下が含まれる。
- あらかじめデザインをしないこと
- 要求を後になって変更すること
- アーキテクチャを後になって変更すること
- 段階的な成長
Yoder氏によれば、Agileは、プロセスとしてではなく、技術的に優れていることへの継続的な注視のようなプラクティス、レトロスペクティブ、面と向かって会話すること、やる気ある個人といったことによって助けとなりうるものである。Yoder氏の提案するツールの一つはソフトウェアがデグレードするたびに行うシンプルなリファクタリングとテスティングである。したがって、泥を小さくする助けになるのはプロセスではなく、究極的には責任感ある開発者であり、彼らが立ち上がり、注目されなければならない、ということだろう。それが起こらない限り、アジャイルな泥だんごもアジャイルでない泥だんごも今のまま存在し続けかねない。
Dave氏が言うように、
うまく分割されたコードの作成を促し、手助けする開発手法の出現や、ソフトウェアクラフトマンシップ運動の高まりにもかかわらず、Big Ball of Mud は最も人気あるソフトウェア設計方法である。そして、その中には過去のひどい設計手法に関する後知恵の恩恵をたっぷり受けた更地開発もふくんでいる。