Webanwendungen

Die meisten Projekte scheitern nicht an der Technik. Sie scheitern daran, dass zu Beginn niemand ausgesprochen hat, was die Anwendung eigentlich leisten soll. Die Lücke fällt dann erst auf, wenn schon drei Monate Arbeit drinstecken.

Deshalb beginnt jedes Projekt bei mir mit dem fachlichen Ablauf, nicht mit der Technologieauswahl. Erst wenn klar ist, welcher Prozess abgebildet wird und wo er in zwei Jahren stehen soll, entscheide ich über Datenmodell und Architektur.

Der Prozess wird aufgezeichnet, bevor Code entsteht

In den ersten Terminen zeichnen wir den Ablauf auf, den die Anwendung tragen soll. Wer legt einen Vorgang an, wer prüft ihn, wer darf ihn sehen, was passiert bei einem Abbruch mittendrin. Aus dieser Skizze entsteht das Datenmodell, und aus dem Datenmodell ergibt sich ein großer Teil der Architektur von allein. Der Aufwand dafür liegt bei ein bis zwei Tagen. Er spart erfahrungsgemäß Wochen, weil Missverständnisse auffallen, solange sie noch nichts gekostet haben.

Laravel im Backend, die Frontend-Frage fällt zu Beginn

Ich arbeite mit Laravel auf PHP 8.5. Zwei Gründe sind mir dabei wichtiger als jede Sprachdebatte. Erstens gibt es für die Bausteine, die man nicht selbst schreiben sollte, geprüfte Pakete: Authentifizierung, Warteschlangen, Dateiablage, Zeitsteuerung. Zweitens finden Sie am Markt Entwickler, die damit umgehen können, falls die Zusammenarbeit mit mir irgendwann endet.

Ob Vue.js die ganze Oberfläche trägt, entscheide ich daran, ob die Anwendung um eine Schnittstelle herum gebaut wird. Greifen mehrere Clients auf dieselben Daten zu, eine mobile App etwa oder ein angebundenes Partnersystem, dann steht die Schnittstelle ohnehin im Zentrum, und Vue.js übernimmt das Frontend als einer dieser Clients. Bleibt es bei der Weboberfläche, liefert der Server die fertigen Seiten aus (Blade). Das erspart eine zweite Anwendung, die gebaut und mitgewartet werden muss. Vue.js sitzt dann als Baustein in den Masken, die ihn brauchen: Formularstrecken mit Abhängigkeiten zwischen den Feldern, Listen mit Filtern, Planungsansichten.

Was ich vermeide, ist die Mischung beider Bauarten in einer Anwendung, ein Bereich über die Schnittstelle, der nächste als Serverseite. Routing und Fehlerdarstellung gibt es dann doppelt, dazu zwei Denkweisen im selben Projekt. Wer die Anwendung später übernimmt, muss beide kennen.

Die erste produktive Version deckt weniger ab als die Wunschliste

Ich schneide den Umfang bewusst klein. In die erste Version kommt, was den fachlichen Prozess einmal von Anfang bis Ende durchlaufen lässt. Alles andere wird notiert und in spätere Etappen einsortiert. Der Grund ist nüchtern: Sobald echte Nutzer mit der Anwendung arbeiten, verschiebt sich die Prioritätenliste. Funktionen, die in der Planung unverzichtbar wirkten, werden nie aufgerufen. Andere, an die niemand gedacht hatte, sind nach zwei Wochen dringend.

Tests und Auslieferung laufen ab dem ersten Tag

Automatisierte Tests schreibe ich mit Pest. Vollabdeckung ist dabei kein Ziel. Getestet wird, was Geld bewegt oder Daten verändert. Die Auslieferung läuft über GitHub Actions, in Unternehmen mit vorhandener Infrastruktur auch über Jenkins. Jeder Push auf den Hauptzweig fährt die Testsuite, baut das Container-Image und stellt es bereit. Ein Deployment dauert dann Minuten. Wichtiger als die Geschwindigkeit ist mir, dass der Weg zurück genauso einfach ist, wenn im Betrieb etwas auffällt.

Am Ende steht ein Projekt, das jemand anderes fortführen kann

Sie erhalten die vollständigen Nutzungsrechte am Code, dazu Repository, Dokumentation und Zugänge. Ich schreibe ihn so, dass er auch dann noch verständlich ist, wenn jemand anderes übernimmt. Dazu gehören sprechende Namen, wenig Magie im Aufbau und ein README, mit dem sich das Projekt in einer halben Stunde lokal starten lässt. Eine freiberufliche Zusammenarbeit endet irgendwann. Dass sie endet, sollte für Sie keine vermeidbaren Kosten verursachen.