In vielen Legacy-Systemen sieht man etwas, das ich „Balcony-Architecture“ nenne. Es ist kein offizielles Muster, beschreibt aber ein reales Problem, das mir in Modernisierungsprojekten häufig begegnet.

Was ist Balcony-Architecture?

Stellen Sie sich ein altes Gebäude vor. Es ist stabil, aber niemand versteht wirklich, wie es gebaut wurde. Eines Tages braucht jemand mehr Platz und fügt einen modernen Balkon an der Seite hinzu. Aber anstatt ihn richtig mit dem Haus zu verbinden, wird er einfach irgendwie angebracht. Es funktioniert, sieht aber seltsam aus und ist nicht wirklich sicher.

In der Software passiert das, wenn ein Entwickler eine neue Funktion hinzufügt, ohne den bestehenden Code zu verändern. Der Grund ist oft einfach: Der Entwickler versteht das System nicht oder hat Angst, den alten Code zu ändern. Also schreibt er neuen Code „neben“ dem System und verbindet ihn gerade so, dass es funktioniert.

Warum Entwickler Balkone bauen

Hier sind die häufigsten Gründe, warum Entwickler diesen Ansatz wählen:

  • Der Code ist schwer zu verstehen und schlecht dokumentiert
  • Es besteht die Angst, bestehende Logik zu zerstören
  • Das System ist über viele Jahre gewachsen und niemand kennt alle Details
  • Das Team steht unter Druck, neue Features schnell zu liefern
  • Es gibt keine Zeit oder keine Erlaubnis zum Refactoring

Dies führt zu der Entscheidung: „Ich füge diesen neuen Teil einfach an der Seite hinzu. Es funktioniert vorerst.“

Anzeichen für Balkon-Architektur

Man erkennt Balkon-Code oft an folgenden Symptomen:

  • Neuer Code befindet sich in separaten Klassen oder Modulen wie NewFeatureHelper, FeatureXAdapter oder FeatureYService2
  • Der neue Teil wiederholt bereits vorhandene Logik, weil der Entwickler die Originalversion nicht ändern wollte
  • Die Integration ist schwach: der neue Code hängt vom alten Code ab, aber die Verbindung ist unklar oder fragil
  • Der alte Code wird wie eine „Black Box“ behandelt und nie angefasst
  • Mit der Zeit wächst das System in seltsame Richtungen, mit vielen kleinen „Balkonen“ an der Seite

Beispiel

In einem Order-Management-System gibt es Preisberechnungslogik, und jede neue Preisregel wird als neue Methode in einer Hilfsklasse hinzugefügt. Die Klasse erhält viele Methoden wie calculatePriceForSpecialCase1(), calculatePriceForBlackFriday() usw. Niemand will die Originallogik anfassen, also fügt jeder Entwickler einen weiteren Balkon hinzu. Am Ende weiss niemand mehr, wie der Endpreis berechnet wurde.

Warum Balcony-Architecture gefährlich ist

Zunächst wirkt dieser Code harmlos. Er löst das Problem, ohne fragile Teile zu berühren. Mit der Zeit entstehen jedoch grosse Probleme:

  • Das System wird schwerer wartbar
  • Bugs treten auf, weil ähnliche Logik dupliziert wird
  • Die Struktur ist nicht mehr klar
  • Neue Entwickler brauchen länger, um alles zu verstehen
  • Technische Schulden wachsen mit jeder neuen Funktion

Was Sie stattdessen tun können

Wenn Sie bemerken, dass Sie oder Ihr Team Balkone hinzufügen, können Sie folgende Schritte unternehmen:

  • Sprechen Sie über das Problem. Geben Sie ihm einen Namen. Sobald Sie es erkennen, können Sie es angehen.
  • Versuchen Sie, den bestehenden Code zu verstehen, bevor Sie etwas Neues hinzufügen.
  • Schreiben Sie Tests, um den Legacy-Code vor dem Refactoring zu schützen.
  • Refaktorieren Sie in kleinen Schritten. Auch kleine Verbesserungen helfen.
  • Arbeiten Sie paarweise mit anderen Entwicklern, wenn Sie an schwierigen Teilen des Systems arbeiten.
  • Dokumentieren Sie Bereiche, die schwer zu verstehen sind.
  • Bitten Sie um Zeit und Unterstützung vom Product Owner oder Manager, um alte Teile zu bereinigen.

Ein positiver Kulturwandel

Balkon-Architektur ist oft ein Zeichen von Angst. Entwickler fühlen sich unsicher, das System zu ändern. Eine gute Teamkultur hilft sehr. Teams sollten sich unterstützt fühlen, wenn sie den Code verbessern wollen, und nicht nur Funktionen liefern.

Konklusio

Balcony-Architecture ist ein Warnsignal. Sie zeigt, dass das System schwer zu verstehen und riskant zu ändern ist. Ignoriert man dies, führt es zu mehr Komplexität und langsamerem Fortschritt.

Anstatt einen weiteren „Balkon“ hinzuzufügen, sollten wir die Struktur Schritt für Schritt verbessern. Ein solides System ist besser als eines mit 20 seltsamen Erweiterungen.