Big Ball of Mud (englisch für „große Matschkugel“) bezeichnet in der Informatik ein Computerprogramm, das keine erkennbare Softwarearchitektur besitzt. Die häufigsten Ursachen dafür sind ungenügende Erfahrung, fehlendes Bewusstsein für Softwarearchitektur, Fluktuation der Mitarbeiter sowie Druck auf die Umsetzungsmannschaft. Obwohl derartige Systeme aus Wartbarkeitsgründen unerwünscht sind, sind sie dennoch häufig anzutreffen, daher gilt Big Ball of Mud als Anti-Pattern der Softwarearchitektur.
Software Der Ausdruck „Big Ball of Mud“ wurde von Brian Foote und Joseph Yoder in ihrem 1999 erschienenen Artikel selben Namens geprägt. Sie definieren Big Ball of Mud folgendermaßen:
Big-Ball-of-Mud-Systeme werden üblicherweise über einen langen Zeitraum durch verschiedene Leute ohne Überblick über das Gesamtsystem entwickelt. Es wurde keine Architektur definiert oder niemand kümmert sich um die Einhaltung der definierten Architektur. Systeme, welche von Entwicklern ohne Ausbildung und Erfahrung mit Softwarearchitektur umgesetzt werden, entwickeln sich oft zu Big-Ball-of-Mud-Systemen.
Foote und Yoder zeigten auf, dass derartige Systeme nicht grundsätzlich abzulehnen sind, da sie in der Softwareentwicklung in der Praxis – wenn auch mit enormen Kosten – funktionieren. In späteren Phasen wie Test und Wartung muss allerdings mit enormen Kosten gerechnet werden. Die Mittel dafür sind allerdings zumeist leichter aufzustellen, als dafür, das System durch eine risikoreiche, komplette Neuentwicklung zu ersetzen.
Alternativ zu einer Fortführung von Big-Ball-of-Mud-Projekten oder einer Neuentwicklung ist ein Refactoring der Architektur.Architecture Refactoring Dabei wird zunächst die Zielarchitektur des Systems im Sinne von großen Architekturbestandteilen wie Schichten oder Komponenten neu definiert, danach die bestehenden Module wie Klassen, Interfaces und Pakete den Komponenten der Zielarchitektur zugewiesen und schlussendlich die gemäß der Zielarchitektur verbotenen Abhängigkeiten aufgezeigt. Basierend auf diesem Soll-Ist-Vergleich können danach die verbotenen Abhängigkeiten sukzessive aufgelöst werden. Dies kann beispielsweise durch ein Umdrehen der Abhängigkeiten (dependency inversion) erfolgen. Damit kann die Big-Ball-of-Mud-Architektur sukzessive in eine definierte, neue Architektur übergeführt werden ohne die in der Software enthaltene Fachlichkeit zu verlieren oder das Risiko einer Neuentwicklung zu tragen.
Programmiersprachen In der Diskussion zur Programmiersprache Lisp wird der Begriff Big Ball of Mud anders verwendet, nämlich im positiven Sinne. Hier bezeichnet er die Gestaltbarkeit eines Lisp-Systems. In Lisp ist es möglich, mittels Makros die Syntax von Lisp zu erweitern, um Lisp ähnlich einer domänenspezifischen Sprache an die Fachlichkeit der Anwendung anzupassen. Außerdem kann man in Lisp Programmteile zur Übersetzungszeit statt zur Laufzeit ausführen oder ein Speicherabbild eines modifizierten Lisp-Systems erstellen.
Die Programmiersprache Forth weist ähnliche Eigenschaften wie Lisp auf und wurde daher ebenfalls als Big Ball of Mud bezeichnet.
Siehe auch Entwurfsmuster Technische Schulden Clean Code
Literatur
Weblinks von Brian Foote am 28. August 2007 aus dem Google Tech Talk Archive (englisch)
Einzelnachweise
Kategorie:Anti-Pattern Kategorie:Lisp