Komplexität ist kein Qualitätsmerkmal
Moderne Webentwicklung bietet für beinahe jedes Problem mehrere Frameworks, Dienste, Bibliotheken und Architekturmuster. Diese Auswahl ist wertvoll, kann aber zu einer falschen Schlussfolgerung führen: dass ein Projekt umso professioneller sein müsse, je mehr technische Bausteine darin vorkommen. Tatsächlich sagt die Anzahl eingesetzter Technologien zunächst wenig über die Qualität einer Lösung aus. Entscheidend ist, ob die gewählte Architektur zur tatsächlichen Aufgabe passt.
Eine zusätzliche technische Schicht bringt nicht nur neue Möglichkeiten mit sich. Sie muss eingerichtet, verstanden, aktualisiert, getestet und langfristig gewartet werden. Sie kann Abhängigkeiten erzeugen und neue Fehlerquellen eröffnen. Deshalb betrachten wir Komplexität nicht als kostenlosen Bestandteil eines Projekts, sondern als etwas, das einen nachvollziehbaren Nutzen rechtfertigen muss. Gibt es diesen Nutzen nicht, ist die einfachere Lösung häufig die belastbarere.
Erst das Problem verstehen, dann die Technik auswählen
Unsere technische Planung beginnt deshalb nicht mit der Frage, welche Werkzeuge wir einsetzen könnten. Zuerst geht es darum, was eine Seite oder Anwendung tatsächlich leisten muss. Welche Inhalte verändern sich regelmäßig? Wo gibt es echte Interaktion? Welche Daten müssen verarbeitet werden? Welche Teile können bereits beim Build vollständig erzeugt werden? Erst aus diesen Anforderungen ergibt sich, welche technische Lösung sinnvoll ist.
Das verhindert Architekturentscheidungen auf Vorrat. Ein redaktioneller Inhalt benötigt beispielsweise nicht automatisch eine Datenbank, nur weil eine Datenbank später theoretisch nützlich sein könnte. Eine überwiegend statische Seite benötigt nicht automatisch clientseitiges JavaScript für Bereiche, die der Browser bereits als fertiges HTML erhalten kann. Wenn sich die Anforderungen verändern, darf auch die Architektur wachsen. Sie muss diese Entwicklung aber nicht spekulativ vorwegnehmen.
Statische Inhalte sind oft eine solide Grundlage
Für Heaviside Solutions bedeutet dieser Ansatz unter anderem, statische Inhalte dort zu bevorzugen, wo sie fachlich sinnvoll sind. Viele Seiten der Website bestehen aus Informationen, deren Darstellung nicht erst bei jedem Seitenaufruf neu berechnet werden muss. Solche Inhalte können früh erzeugt und anschließend effizient ausgeliefert werden. Das reduziert unnötige Laufzeitlogik und schafft eine vergleichsweise übersichtliche technische Grundlage.
Auch innerhalb von React unterscheiden wir bewusst zwischen dem, was auf dem Server beziehungsweise während der Erzeugung einer Seite erledigt werden kann, und dem, was tatsächlich Interaktivität im Browser benötigt. Clientseitige Komponenten haben ihren Platz, aber nicht jede Komponente muss eine sein. Weniger JavaScript im Browser ist für uns kein Selbstzweck. Es ist eine Folge davon, Funktionen dort auszuführen, wo sie für die jeweilige Aufgabe sinnvoll aufgehoben sind.
Keine Systeme nur deshalb einführen, weil sie üblich sind
Dasselbe Prinzip gilt für größere Infrastrukturentscheidungen. Ein Content-Management-System kann für redaktionelle Teams und häufig wechselnde Inhalte sehr sinnvoll sein. Eine Datenbank ist unverzichtbar, sobald dauerhaft veränderliche Anwendungsdaten zuverlässig gespeichert werden müssen. Ein globaler State-Manager kann komplexe Zustände erheblich vereinfachen. Daraus folgt aber nicht, dass jedes Projekt diese Systeme von Beginn an benötigt.
Bei Heaviside Solutions verwalten wir überschaubare redaktionelle Daten derzeit bewusst lokal und validieren sie bereits technisch. Dadurch bleibt nachvollziehbar, welche Inhalte zur Website gehören und welche Anforderungen sie erfüllen müssen. Würde dieser Ansatz irgendwann zum Hindernis, wäre das ein konkreter Grund für eine neue Lösung. Der entscheidende Unterschied liegt darin, Technik aufgrund eines vorhandenen Problems einzuführen und nicht aufgrund eines Problems, das vielleicht irgendwann entstehen könnte.
Einfacher bedeutet nicht nachlässiger
Eine reduzierte Architektur darf nicht mit reduzierten Qualitätsansprüchen verwechselt werden. Weniger technische Bausteine ersetzen weder saubere Typisierung noch Validierung, Tests, Barrierefreiheit oder Sicherheitsmaßnahmen. Gerade eine überschaubare Architektur sollte konsequent abgesichert werden. Fehler früh zu erkennen ist wesentlich wertvoller, als sie erst nach einer Veröffentlichung über Besucher oder Suchmaschinen zu entdecken.
Deshalb gehören bei uns Prüfungen von Datenstrukturen, Typechecks, Linting, Produktions-Builds und Browser-Tests zur technischen Arbeit. Auch Veröffentlichungszustände, Metadaten, Sitemap und zentrale Seiteneigenschaften werden nicht dem Zufall überlassen. Das Ziel lautet also nicht, möglichst wenig Technik einzusetzen. Das Ziel ist, nur die Technik einzusetzen, die eine klare Aufgabe übernimmt, und diese anschließend sorgfältig zu betreiben.
Auch technische Trennung reduziert unnötige Abhängigkeiten
Ein weiterer Teil dieser Haltung ist die bewusste Trennung unserer Projekte. Heaviside Solutions, Revora, BillDrift, ScopeLedger und Elanvoro erfüllen unterschiedliche Aufgaben. Eine gemeinsame technische Universalplattform würde auf den ersten Blick möglicherweise vereinfachend wirken. In der Praxis müsste sie jedoch sehr unterschiedliche Anforderungen gleichzeitig abbilden und würde dadurch neue Abhängigkeiten zwischen Bereichen schaffen, die fachlich gar nicht voneinander abhängen müssen.
Eigenständige technische Grundlagen erlauben dagegen, Entscheidungen am jeweiligen Projekt auszurichten. Eine redaktionell geprägte Plattform hat andere Anforderungen als ein Lagersystem oder eine B2B-Analyseanwendung. Änderungen an einem Bereich müssen nicht automatisch Auswirkungen auf alle anderen haben. Die gemeinsame Verbindung entsteht auf Ebene der Verantwortung und der Dachmarke, nicht durch den Versuch, unterschiedliche Systeme technisch in dieselbe Form zu zwingen.
Wann zusätzliche Komplexität die richtige Entscheidung ist
Es gibt selbstverständlich Situationen, in denen eine komplexere Lösung die bessere ist. Wenn Nutzerkonten, veränderliche Daten, umfangreiche Berechtigungen, externe Schnittstellen oder anspruchsvolle Geschäftslogik benötigt werden, reicht eine rein statische Architektur nicht aus. Auch wachsende redaktionelle Abläufe können irgendwann ein spezialisiertes System rechtfertigen. In solchen Fällen wäre es ebenso falsch, aus Prinzip an einer möglichst einfachen Lösung festzuhalten.
Unsere Entscheidungsregel ist deshalb nicht, Komplexität zu vermeiden. Sie soll begründet sein. Eine zusätzliche Abhängigkeit ist sinnvoll, wenn ihr Nutzen die dadurch entstehenden Kosten und Risiken überwiegt. Architektur darf wachsen, wenn die Aufgabe wächst. Diese Haltung lässt Raum für leistungsfähige Systeme, ohne jedes neue Projekt vorsorglich mit einer Infrastruktur auszustatten, deren Möglichkeiten möglicherweise nie benötigt werden.
Wartbarkeit ist ein langfristiges Qualitätsmerkmal
Technische Entscheidungen zeigen ihre Qualität häufig nicht am Tag der Veröffentlichung. Interessanter wird es Monate oder Jahre später: Lässt sich noch nachvollziehen, warum ein bestimmter Aufbau gewählt wurde? Können Abhängigkeiten sicher aktualisiert werden? Ist eine Änderung an einer Stelle möglich, ohne unbeabsichtigt mehrere andere Bereiche zu beeinflussen? Je größer ein Projekt wird, desto wichtiger werden solche Fragen.
Deshalb gehört Verständlichkeit für uns zur technischen Qualität. Ein System muss nicht primitiv sein, um verständlich zu bleiben. Es braucht aber klare Zuständigkeiten, nachvollziehbare Datenflüsse und möglichst wenige unnötige Sonderfälle. Wenn zwei Lösungen dieselbe Aufgabe zuverlässig erfüllen, bevorzugen wir grundsätzlich diejenige, die langfristig leichter zu verstehen, zu prüfen und weiterzuentwickeln ist. Technische Reife zeigt sich für uns nicht darin, wie viel Architektur sichtbar ist, sondern darin, wie wenig davon ohne guten Grund vorhanden sein muss.