Big Ball of Mud

Begriff und Bedeutung

Ein Big Ball of Mud ist ein Computerprogramm ohne erkennbare Softwarearchitektur. Seine Struktur ist planlos, unübersichtlich und von Spaghetti-Code, ungehemmtem Wachstum sowie wiederholten Behelfsreparaturen geprägt. Informationen sind oft wahllos über weit voneinander entfernte Teile verteilt, global verfügbar oder mehrfach vorhanden. Eine Architektur wurde entweder nie klar festgelegt oder ist im Laufe der Entwicklung bis zur Unkenntlichkeit zerfallen.

Solche Systeme gelten als Anti-Pattern der Softwarearchitektur: Sie sind wegen ihrer schlechten Wartbarkeit unerwünscht, kommen in der Praxis aber häufig vor.

Ursachen und praktische Folgen

Big-Ball-of-Mud-Systeme entstehen üblicherweise über einen langen Zeitraum und werden von verschiedenen Personen weiterentwickelt, denen der Überblick über das Gesamtsystem fehlt. Typische Ursachen sind ungenügende Erfahrung, fehlendes Bewusstsein oder fehlende Ausbildung im Bereich Softwarearchitektur, Mitarbeiterfluktuation und hoher Umsetzungsdruck. Auch eine vorhandene Architektur hilft nicht, wenn ihre Regeln nicht eingehalten werden.

Foote und Yoder weisen darauf hin, dass solche Systeme nicht grundsätzlich unbrauchbar sind: Sie können in der Praxis funktionieren, allerdings mit enormen Kosten. Besonders in späteren Phasen wie Test und Wartung steigt der Aufwand stark. Trotzdem kann ihre Weiterführung leichter zu finanzieren sein als eine vollständige Neuentwicklung, die zusätzliche Risiken mit sich bringt.

Schrittweises Architektur-Refactoring

Eine Alternative zur bloßen Fortführung oder kompletten Neuentwicklung ist ein Refactoring der Architektur, also eine schrittweise Umgestaltung der Struktur bei Erhalt der enthaltenen Fachlogik.

Dabei wird zuerst eine Zielarchitektur mit großen Bestandteilen wie Schichten oder Komponenten festgelegt. Anschließend ordnet man bestehende Module – etwa Klassen, Interfaces und Pakete – diesen Bestandteilen zu. Danach werden Abhängigkeiten ermittelt, die nach der Zielarchitektur nicht erlaubt sind. Dieser Soll-Ist-Vergleich zeigt, welche Verbindungen schrittweise aufgelöst werden müssen.

Eine mögliche Methode ist die Dependency Inversion, also das Umdrehen von Abhängigkeiten. So lässt sich ein Big Ball of Mud nach und nach in eine definierte Architektur überführen, ohne die fachlichen Funktionen der Software zu verlieren oder das Risiko einer vollständigen Neuentwicklung einzugehen.

Abweichende Bedeutung bei Lisp und Forth

In der Diskussion über die Programmiersprache Lisp wird Big Ball of Mud positiv verwendet. Der Ausdruck bezeichnet dort die starke Gestaltbarkeit eines Lisp-Systems. Mit Makros lässt sich die Syntax erweitern und an die Fachlichkeit einer Anwendung anpassen, sodass Lisp einer domänenspezifischen Sprache ähneln kann.

Außerdem können in Lisp Programmteile bereits zur Übersetzungszeit statt erst zur Laufzeit ausgeführt werden. Ebenso lässt sich ein Speicherabbild eines veränderten Lisp-Systems erstellen. Forth besitzt ähnliche Eigenschaften und wurde deshalb ebenfalls als Big Ball of Mud bezeichnet.