Was ist der „Big Ball of Mud“?
Brian Foote und Joseph Yoder definierten einen Big Ball of Mud folgendermassen:
„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
Ein solcher Big Ball of Mud kann also als „grosse Matschkugel“ betrachtet werden, in welcher über einen gewissen Zeitraum immer mehr Code hineingequetscht wurde, ohne, dass man sich um eine grundlegende Architektur gekümmert, oder diese zumindest über einen längeren Zeitraum vernachlässigt hat.
Wieso entsteht der „Big Ball of Mud“?
Die Entstehung des „Big Ball of Mud“ kann durch verschiedene Einflüsse begünstigt werden. Dazu zählen unter Anderem die folgenden:
Zeit und Kosten
Der Entwurf einer guten Architektur benötigt Zeit und bringt hohe Kosten mit sich. Während der Entwicklung sind die Vorteile der Architektur oft nicht direkt zu erkennen. Dieser ist meist erst zu einem späteren Zeitpunkt zu erkennen, z.B. wenn Anpassungen an der Software notwendig sind und diese sich durch eine vorausschauende Architektur leichter umsetzen lassen.
Dies kann schnell dazu führen, dass schneller umsetzbare Lösungen einer „sauberen“ Implementierung vorgezogen werden, da diese meist ebenfalls günstiger scheint. Architektur wird quasi zu einem Luxus.
Dies kann schnell dazu führen, dass schneller umsetzbare Lösungen einer „sauberen“ Implementierung vorgezogen werden, da diese meist ebenfalls günstiger scheint. Architektur wird quasi zu einem Luxus.
Erfahrung des Teams
Unerfahrene Mitarbeiter im Team die noch nicht viel Software entwickelt haben, sowie Mitarbeiter die nicht den vollen Überblick über die bestehende Architektur haben, können die Auswirkungen ihrer Implementierungen auf das Gesamtsystem oft schlecht abschätzen. Wird versäumt die Architektur der Software regelmässig zu refactoren, kann dies stark zur Entwicklung des „Big Ball of Mud“ beitragen.
Sichtbarkeit
Im Vergleich zur Architektur von Gebäuden ist die Architektur einer Software nur für die Entwickler nicht jedoch für die Anwender zu erkennen. Diese sehen nur die Bedienschnittstelle (die Fassade). Dies kann dazu führen, dass die Architektur der Software als nicht so wichtig wahrgenommen wird, und unsaubere Implementierungen so unter den Teppich gekehrt werden nach dem Motto: „Sieht ja eh keiner.“
Änderungen
Ist die Software erst einmal fertig und in Benutzung kommt es sehr oft vor, dass sich die Anforderungen ändern oder neue Features gewünscht werden. Werden über einen langen Zeitraum viele Änderungen eingeflegt und die Architektur nicht regelmässig refactort, kann dies dazu führen, dass die Qualität der Software kontinuierlich abnimmt.
Startet ein Projekt auf der grünen Wiese, also eine komplette Neuentwicklung kann ein Big Ball of Mud a priori verhindert werden, indem gleich zu Beginn eine saubere Architekturplanung erfolgt. Während der Lebensdauer des Projektes sollte diese immer wieder unter die Lupe genommen werden und gegebenfalls an geänderte Anforderungen angepasst werden.
Bei bereits bestehenden Matschkugeln kann ein gezieltes Refactoring die Situation deutlich entschärfen. Auch hier gilt es zu beachten, dass der Architektur die nötige Aufmerksamkeit geschenkt wird. In beiden Fällen ist es wichtig, dass Anti-Pattern frühzeitig erkannt und eliminiert werden.
