Eine Webanwendung wird nicht dadurch schlecht, dass sie alt ist. Sie wird schlecht, wenn niemand mehr erklären kann, warum sie so gebaut wurde.
Typische Ausgangslagen
- Eine Anwendung funktioniert, aber jede Änderung dauert länger als die vorherige.
- Der Frontend-Stack lässt sich nicht mehr aktualisieren, ohne die halbe Anwendung anzufassen.
- Fachlogik verteilt sich über Templates, Datenbank-Trigger und ein gewachsenes Skriptverzeichnis.
- Eine Plattform soll mehrere Mandanten bedienen, wurde aber für einen gebaut.
Technische Aufgaben
- Anwendungen mit klarer Schichtung und expliziten Zuständigkeiten entwerfen
- Serverseitiges Rendering, wo Inhalte ohne JavaScript erreichbar sein müssen
- Bestehende Anwendungen schrittweise entflechten statt sie komplett neu zu schreiben
- Datenmodelle so gestalten, dass sie fachliche Änderungen überstehen
- Betrieb, Deployment und Rollback von Anfang an mitdenken
Vorgehen
Technologieentscheidungen werden begründet und schriftlich festgehalten – einschließlich dessen, was bewusst nicht verwendet wird. Ein Framework, das eine Aufgabe kurzfristig vereinfacht, aber die Anwendung dauerhaft an eine Versionslinie bindet, ist selten die günstigere Wahl.
Systemkontext
Diese Website ist ein Beispiel für diese Arbeitsweise: serverseitig gerendert, ohne Datenbank, ohne clientseitiges Framework, mit Inhalten als versionierte Markdown-Dateien. Die Architekturentscheidungen sind im Repository dokumentiert und nicht in einem Konfigurationsdialog versteckt.