Big Ball of Mud

In der Informatik bezeichnet ein Big Ball of Mud (englisch für „große Matschkugel“) ein Programm, 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:

“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.”

„Ein Big Ball of Mud ist ein planlos strukturierter, ausufernder, schlampiger, mit Klebeband und Bindedraht zusammengehaltener 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.“

– Brian Foote, Joseph Yoder: Big Ball of Mud. Fourth Conference on Patterns Languages of Programs (PLoP ’97 / EuroPLoP ’97) Monticello, Illinois, September 1997[1]

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.[2] 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

Literatur
  • Brian Foote, Joseph Yoder: Big Ball of Mud. Hrsg.: Department of Computer Science, University of Illinois at Urbana-Champaign. 26. Juni 1999 (laputan.org [abgerufen am 14. Februar 2012]).
  • Brian Foote, Joseph Yoder: Pattern Languages of Program Design 4 (= Software Patterns. Band 4). Addison-Wesley, 1999, ISBN 0-201-43304-4, Kap. 29 (englisch).

Einzelnachweise
  1. Brian Foote, Joseph Yoder: Big Ball of Mud. Hrsg.: Department of Computer Science, University of Illinois at Urbana-Champaign. 26. Juni 1999 (laputan.org [abgerufen am 14. Februar 2012]).
  2. Architecture Refactoring
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.