Quelltext der Seite Big Ball of Mud

'''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 [[Wartbarkeit]]sgrü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:

{{Zitat
 |Text=A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.
 |Sprache=en
 |Autor=Brian Foote, Joseph Yoder
 |Quelle=''Big Ball of Mud.'' Fourth Conference on Patterns Languages of Programs (PLoP ’97 / EuroPLoP ’97) Monticello, Illinois, September 1997
 |Übersetzung=Ein Big Ball of Mud ist ein planlos strukturierter, ausufernder, schlampiger, mit Klebeband und Bindedraht zusammengehaltener [[Spaghetticode|Spaghetti-Code]]-Dschungel. Derartige Systeme weisen eindeutige Anzeichen von ungehemmtem Wachstum und ständigen Behelfsreparaturen auf. Die in diesen Systemen enthaltenen Informationen sind wahllos über die entferntesten Elemente verteilt, oft bis zu dem Punkt, wo fast alle wichtigen Informationen global oder dupliziert sind. Die Architektur derartiger Systeme wurde vielleicht nie richtig definiert, und wenn doch ist sie bis zur Unkenntlichkeit erodiert. Programmierer mit einem Fetzen architektonischer Sensibilität meiden derartige Sümpfe. Nur diejenigen, die sich nicht um Architektur scheren und vielleicht sogar gerne Tag für Tag mühsam Löcher in undichten Deichen stopfen, arbeiten gerne mit solchen Systemen.
 |ref=<ref>{{Literatur |Autor=Brian Foote, Joseph Yoder |Hrsg=Department of Computer Science, University of Illinois at Urbana-Champaign |Titel=Big Ball of Mud |Datum=1999-06-26 |Online=http://www.laputan.org/mud/ |Abruf=2012-02-14}}</ref>}}

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.<ref>[http://stal.blogspot.com/2007/01/architecture-refactoring.html Architecture Refactoring]</ref> 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 [[Makro]]s die [[Syntax]] von Lisp zu erweitern, um Lisp ähnlich einer [[Domänenspezifische Sprache|domänenspezifischen Sprache]] an die Fachlichkeit der Anwendung anzupassen. Außerdem kann man in Lisp Programmteile zur [[Übersetzungszeit]] statt zur [[Laufzeit (Informatik)|Laufzeit]] ausführen oder ein [[Image-Datei|Speicherabbild]] eines modifizierten Lisp-Systems erstellen.

Die Programmiersprache [[Forth (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 ==
* {{Literatur
   |Autor=Brian Foote, Joseph Yoder
   |Hrsg=Department of Computer Science, University of Illinois at Urbana-Champaign
   |Titel=Big Ball of Mud
   |Datum=1999-06-26
   |Online=[http://www.laputan.org/mud/ laputan.org]
   |Abruf=2012-02-14}}
* {{Literatur
   |Autor=Brian Foote, Joseph Yoder
   |Titel=Pattern Languages of Program Design 4
   |Reihe=Software Patterns
   |BandReihe=4
   |Verlag=Addison-Wesley
   |Datum=1999
   |ISBN=0-201-43304-4
   |Kapitel=29
   |Sprache=en}}

== Weblinks ==
* {{YouTube |id=h6Y9aJhqO78 |titel=Video des Vortrags “Big Ball of Mud”}} von Brian Foote am 28. August 2007 aus dem Google Tech Talk Archive (englisch)

== Einzelnachweise ==
<references />

[[Kategorie:Anti-Pattern]]
[[Kategorie:Lisp]]