Wartbare Frontend-Systeme: Wie Einschränkungen zu besserer Codequalität führen

Warum wir immer wieder Software neu schreiben – und wie wir den Kreislauf durchbrechen

Die Frage "Warum schreiben wir Software immer wieder neu?" ist vielleicht eine der wichtigsten in der Softwareentwicklung. Viele von uns kennen dieses Gefühl: Wir übernehmen ein Projekt, verstehen den Code nicht vollständig und entscheiden uns für einen Neuanfang, anstatt Zeit in das Verständnis zu investieren. Dieser Kreislauf wiederholt sich in der gesamten Branche und kostet Unternehmen enorm viel Zeit und Ressourcen.

Doch was sind die eigentlichen Gründe? Manchmal ist es schlicht unsere Unerfahrenheit – wir verstehen fremden Code nicht und scheuen den Aufwand, ihn zu durchdringen. In anderen Fällen ist es die reine Freude am Neuschaffen oder die Verfügbarkeit besserer technischer Lösungen. Doch der am häufigsten genannte Grund ist technische Schuld – jenes mysteriöse Konzept, das jeder Entwickler anders definiert.

Was versteht man wirklich unter technischer Schuld?

Technische Schuld wird oft unterschiedlich interpretiert. Für manche ist es "Code, den ich nicht geschrieben habe", für andere "Code, den ich schrieb, bevor ich wusste, was ich tat". Sie kann sich in veralteten Bibliotheken manifestieren oder in Features, die niemand mehr nutzt, aber trotzdem migriert werden müssen.

Eine pragmatische Definition könnte lauten: Technische Schuld ist Code, der wiederholt und negativ die Geschwindigkeit oder Qualität der Entwicklung beeinflusst. Wir kennen den typischen Verlauf – anfangs entwickeln wir auf grüner Wiese mit hoher Geschwindigkeit, doch irgendwann sinkt die Produktivität drastisch. Selbst nach gezielten Refactoring-Maßnahmen rutschen wir oft zurück in alte Muster – wie ein Abonnement für technische Schuld, das wir nicht kündigen können.

Der Second-System-Effekt: Warum Neuentwicklungen oft scheitern

Der bekannte "Second-System-Effekt" beschreibt ein häufiges Phänomen: Das neu entwickelte System ist oft komplizierter und schlechter als das ursprüngliche. Der Erfinder von C++ brachte es prägnant auf den Punkt: "Legacy-Code unterscheidet sich von seiner vorgeschlagenen Alternative oft dadurch, dass er tatsächlich funktioniert und skaliert."

Diese Erkenntnis kann entmutigend wirken. Sind wir als Entwickler dazu verdammt, immer wieder in diesen Kreislauf zu geraten? Die Wahrheit ist: Die realen Kosten von Software liegen nicht in der Erstentwicklung, sondern in der langfristigen Wartung. Anforderungen ändern sich, neue Features werden benötigt, Geschäftsmodelle wandeln sich – und unsere Software muss sich entsprechend anpassen.

Architektur als Schlüssel zu resilienten Systemen

Die eigentliche Frage ist daher nicht, warum wir Software neu schreiben, sondern wie wir Systeme entwickeln können, die resilienter gegenüber Veränderungen sind. Wie können wir erreichen, dass die Geschwindigkeit der Entwicklung mit der Zeit sogar zunimmt, anstatt abzufallen?

Die Antwort – "gute Architektur" – mag zunächst unbefriedigend klingen. Für viele Entwickler ist "Architektur" ein belasteter Begriff. Was macht ein Software-Architekt den ganzen Tag? Der Begriff selbst hat keine einheitliche Definition, und die Antwort "gute Architektur" erscheint oft losgelöst von den alltäglichen Problemen eines Entwicklers.

Architektur neu gedacht: Einschränkungen, die uns schneller machen

Anstatt eine weitere Definition von Architektur zu liefern, lohnt es sich, dieses Konzept neu zu denken: als ermöglichende Einschränkungen (enabling constraints). Dies sind Beschränkungen in der Nutzung von Code und Daten, die uns letztendlich helfen, schneller und sicherer zu arbeiten.

Ein Vergleich mit dem Straßenverkehr verdeutlicht dies: Auf der deutschen Autobahn können Fahrer an bestimmten Stellen ohne Geschwindigkeitsbegrenzung fahren – was theoretisch gefährlich klingt. Doch dank klarer Einschränkungen wie Fahrspuren, physischen Barrieren zwischen Richtungen und Verkehrsregeln ist dies relativ sicher möglich. Die Einschränkungen helfen uns, schnell und sicher zu fahren.

Wie Constraints in der Softwareentwicklung funktionieren

In der Softwareentwicklung haben sich ähnliche Muster etabliert. Die objektorientierte Programmierung (OOP) schränkte uns ein, indem sie uns zwang, unsere Programme in Klassen zu strukturieren – doch genau dadurch konnten wir die Struktur unserer Anwendungen von der Codeorganisation entkoppeln.

Auch die funktionale Programmierung bringt Einschränkungen mit sich, insbesondere durch Unveränderlichkeit (Immutability). Obwohl veränderbare Daten theoretisch mächtiger sind, eliminiert die Unveränderlichkeit ganze Problemklassen, weil verschiedene Teile der Anwendung nicht mehr glauben, sie könnten gemeinsam genutzte Daten nach Belieben verändern.

Im Frontend-Bereich sehen wir ähnliche Entwicklungen: Die Nutzung von "const" statt "var" scheint eine kleine Änderung, bietet aber mehr Sicherheit. Der Wechsel von jQuery zu React entfernte uns von direkter DOM-Manipulation, führte aber zu vorhersehbareren und besser testbaren Benutzeroberflächen. Selbst CSS-in-JS, trotz aller Kontroversen, zwingt uns dazu, Stile explizit zwischen Komponenten zu teilen und vermeidet Seiteneffekte durch globale Namen.

Drei praktische Constraints für resilientere Frontend-Architekturen

Im folgenden Teil werden drei spezifische Einschränkungen vorgestellt, die zu einer resilienteren Frontend-Architektur führen können. Diese sind nicht erschöpfend, aber praktisch anwendbar.

1. Quellcode-Abhängigkeiten bewusst strukturieren

In der Frontend-Entwicklung wird viel über Directory-Strukturen diskutiert, aber weniger darüber, welche Teile der Anwendung von welchen anderen Teilen abhängen dürfen. Es gibt verschiedene Ansätze zur Organisation interner Abhängigkeiten:

Das "Big Ball of Mud"-Prinzip vs. geschichtete Architektur

Der bekannteste Ansatz ist der "Big Ball of Mud" – wenn keine klaren Regeln definieren, was wovon abhängen darf, entsteht meist eine schlammige Umgebung. Alternativ gibt es den geschichteten Ansatz, bei dem klare Regeln für Abhängigkeiten in eine Richtung bestehen, sowie den modularen Ansatz, der kleinere Module mit begrenzten API-Schnittstellen vorsieht.

Der entscheidende Unterschied: Bei einem "Big Ball of Mud" ist der potenzielle Regressionsbereich bei einer Änderung unbekannt. Man kann nicht vorhersagen, was brechen wird. Dies führt oft zu teamübergreifenden Konflikten, wenn Änderungen eines Teams unwissentlich die Arbeit eines anderen Teams beeinträchtigen.

Bei einer geschichteten Architektur hingegen ist der Wirkungsbereich von Änderungen begrenzter und vorhersehbarer. Wenn die Anwendungsorganisation zudem der Teamstruktur entspricht, sind teamübergreifende Auswirkungen besser eingedämmt.

2. Konservativer mit Code-Wiederverwendung umgehen

Als Entwickler lieben wir es, Code zu teilen. Es gibt uns ein gutes Gefühl, wenn wir gemeinsame Abstraktionen schaffen. Doch manchmal binden wir im Namen der DRY-Prinzipien (Don't Repeat Yourself) Codeteile zusammen, die eigentlich nichts voneinander wissen sollten, was den Code anfälliger für Seiteneffekte macht.

Ein typisches Beispiel: Ein Entwickler sieht eine Komponente auf einer Seite, die einer benötigten Komponente auf einer neuen Seite ähnelt. Die Komponente wird generalisiert und in einen gemeinsamen Ordner verschoben – zunächst eine scheinbar gute Idee. Doch mit neuen Anforderungen möchten diese Komponenten divergieren. Die gemeinsame Platzierung hält sie jedoch zusammen, und es entstehen Verzweigungen und bedingte Logik, die die Komponente komplexer machen.

Code-Entkopplung versus DRY

Die wichtige Erkenntnis: Es ist wichtiger, dass Code entkoppelt bleibt, als dass er DRY bleibt. Code-Wiederverwendung ist kein Selbstzweck; ihr Hauptziel ist die Vermeidung unnötiger Fehler. Wenn wir jedoch "Trockenheit" an Stellen einführen, die unzusammenhängenden Code verbinden, eliminieren wir genau den Vorteil, den wir durch DRY erreichen wollten.

Manchmal braucht man einfach "zwei Gläser" – wenn eines zerbricht, sollte das andere nicht zwangsläufig auch weggeworfen werden müssen, nur weil sie als Paar betrachtet wurden. Ein kritischer Blick auf potenzielle Abstraktionen hilft, die Kopplung von Code zu vermeiden, der sich im Laufe der Zeit auseinanderentwickelt.

3. Grenzen technisch durchsetzen

Ein häufiges Szenario: Ein Team entwickelt einen Architekturplan, dokumentiert Entscheidungen in einem Wiki, erstellt Diagramme – und bereits in der folgenden Woche beginnt diese Dokumentation zu verstauben. Neue Features werden entwickelt, ohne die dokumentierte Architektur zu konsultieren.

Verbotene Abhängigkeitstests

Eine effektive Lösung für dieses Problem sind "verbotene Abhängigkeitstests" (forbidden dependency tests). Während herkömmliche Tests das Verhalten einer Anwendung prüfen, testen diese die Struktur der Anwendung aus Abhängigkeitssicht.

Ein Entwickler kann Regeln definieren, die im Rahmen der CI laufen und den Build brechen, wenn jemand versucht, von seinem Code abhängig zu sein. Im Node.js-Ökosystem gibt es dafür Tools wie "dependency cruiser", das auch zirkuläre Abhängigkeiten prüfen kann.

Diese automatisierte Durchsetzung bewahrt die Architektur hinsichtlich ihrer internen Abhängigkeiten im Laufe der Zeit. Anstatt zu warten, bis jemand einen Pull Request öffnet, argumentiert das CI-System für uns – was zu weniger persönlichen Konflikten führt.

Was wir über resiliente Frontend-Architekturen lernen können

Software verändert sich zwangsläufig, weil sich Geschäftsanforderungen und Features ändern. Das bedeutet, dass manchmal ein Umschreiben oder Migrieren unvermeidlich ist. Architektur kann als Anwendung von ermöglichenden Einschränkungen betrachtet werden – Beschränkungen in der Nutzung von Code und Daten, die uns helfen, schneller und sicherer zu arbeiten.

Architektur ist nicht nur Framework-spezifisch

Ein wichtiger Hinweis für die Frontend-Community: Architektur muss nicht von Grund auf neu erfunden werden. Oft suchen Entwickler nach framework-spezifischen Architekturlösungen (React-Architektur, Vue-Architektur), doch viele Probleme sind weder framework- noch webspezifisch – es ist einfach Software.

Frontend-Entwickler sollten offen sein für Erkenntnisse aus anderen Programmiersprachen und Paradigmen. Es ist verlockend zu sagen: "Das ist OOP, das machen wir nicht mehr" oder "Die Beispiele sind in C++, also werde ich dieses Buch nicht lesen". Doch andere Programmiergemeinschaften bauen seit viel längerer Zeit große Anwendungen als die Frontend-Community – wir können von ihnen lernen.

Kleine Änderungen, große Wirkung

Auch als individueller Entwickler trifft man architektonische Entscheidungen. Die Lösung beginnt oft auf Funktions- oder Modulebene, nicht bei großen Frameworks wie Redux oder Flux. Durch bewusstes Denken über Abhängigkeitsrichtungen, kritischem Umgang mit Code-Wiederverwendung und technischer Durchsetzung von Architekturregeln können wir resilientere Systeme schaffen, die auch bei wachsender Komplexität wartbar bleiben.

Mit diesen Prinzipien können wir den Kreislauf ständiger Neuentwicklungen durchbrechen und eine nachhaltigere Zukunft für unsere Frontend-Anwendungen gestalten.

Fazit: Der Weg zu nachhaltigen Frontend-Architekturen

Der Schlüssel zu nachhaltigen Frontend-Architekturen liegt nicht in revolutionären neuen Frameworks oder komplexen Designpatterns, sondern in der bewussten Anwendung von sinnvollen Einschränkungen. Indem wir klare Richtungen für interne Abhängigkeiten definieren, kritisch mit Code-Wiederverwendung umgehen und diese Regeln automatisiert durchsetzen, können wir Systeme schaffen, die auch unter wachsender Komplexität und steigenden Anforderungen wartbar bleiben.

Die größte Herausforderung besteht darin, diese Prinzipien im Alltag zu verankern und gegen die natürliche Tendenz zur Entropie anzukämpfen. Doch mit den richtigen Werkzeugen und einem gemeinsamen Verständnis im Team kann eine resiliente Architektur entstehen, die uns auf lange Sicht Zeit und Ressourcen spart – und den endlosen Kreislauf von Neuentwicklungen durchbricht.

FAQ

Was ist der Unterschied zwischen technischer Schuld und schlechter Codequalität?

Technische Schuld ist Code, der wiederholt und negativ die Geschwindigkeit oder Qualität der Entwicklung beeinflusst. Im Gegensatz zu einfach "schlechtem Code" geht es bei technischer Schuld um die Auswirkungen auf die langfristige Entwicklungsgeschwindigkeit. Technische Schuld entsteht oft durch bewusste Entscheidungen unter Zeitdruck und kann auch in qualitativ hochwertigem Code vorkommen, wenn dieser nicht für zukünftige Anforderungen ausgelegt ist.

Wann sollte ich Code teilen und wann ist Duplizierung besser?

Teile Code, wenn die geteilte Funktionalität stabil ist und sich voraussichtlich nicht in unterschiedliche Richtungen entwickeln wird. Bevorzuge Duplizierung, wenn die Funktionalität in verschiedenen Kontexten unterschiedlichen Anforderungen unterliegt oder wenn die Wahrscheinlichkeit hoch ist, dass sich die Anforderungen auseinanderentwickeln werden. Das DRY-Prinzip sollte nie auf Kosten einer klaren Trennung von Verantwortlichkeiten angewendet werden.

Wie kann ich in einem bestehenden "Big Ball of Mud"-Projekt eine bessere Architektur einführen?

Beginne mit der Identifizierung von natürlichen Grenzen in deiner Anwendung. Definiere klare Module oder Schichten und implementiere verbotene Abhängigkeitstests, um neue Verstöße zu verhindern. Führe dann schrittweise Refactorings durch, um bestehende Verstöße zu beseitigen, beginnend mit den kritischsten Bereichen. Dieser inkrementelle Ansatz ermöglicht kontinuierliche Verbesserungen, ohne das gesamte System neu schreiben zu müssen.