49 lines
4.4 KiB
TeX
49 lines
4.4 KiB
TeX
\section{Reflexion}
|
|
\label{sec:reflection}
|
|
|
|
\subsection{Externe Abhängigkeiten früher klären}
|
|
|
|
Zwischen Antrag und abschließender Auskunft über die verfügbaren Speicherfunktionen lagen vier Wochen — bei einem Projektzeitraum von wenigen Wochen ein erheblicher Anteil.
|
|
|
|
Der Fehler lag im Zeitpunkt: Die fachliche Klärung war seit dem 18.~Juni abgeschlossen; der Antrag folgte über vier Wochen später. Hätte er unmittelbar nach der Feature-Analyse vorgelegen, wäre die Frage nach den Speicherfunktionen früher beantwortet gewesen — die Lookup-Recherche hätte nicht auf eine letztlich negative Antwort warten müssen.
|
|
|
|
Vorgänge, deren Dauer man nicht selbst bestimmt, gehören an den Anfang der Planung. Sie kosten keine Arbeitszeit, aber Wartezeit — und Wartezeit lässt sich nur durch frühes Beginnen verkürzen.
|
|
|
|
\subsection{Eine Architekturentscheidung ist die Summe ihrer Randbedingungen}
|
|
|
|
Das Lookup-Problem war die technisch anspruchsvollste Aufgabe des Projekts.
|
|
|
|
Die zunächst betrachteten Ansätze — Zwischenspeicher, Anmeldetoken, Feld im ITSM-System — waren technisch tragfähig, wurden aber verworfen, weil sie jeweils eine zweite Stelle einführen, an der dieselbe Information gepflegt wird. Die gewählte Lösung ergab sich aus der genauen Betrachtung der Randbedingungen.
|
|
|
|
Ausschlaggebend war die Unterscheidung zwischen Anforderung und vermuteter Umsetzung: Die interne Pflege verlangte eine \emph{Sortierung nach Kundennamen}, nicht zwingend Ordnernamen, die \emph{ausschließlich} aus dem Kundennamen bestehen. Diese Präzisierung machte die Lösung sichtbar; ohne die Rückfrage bei der internen Fachseite wäre der Lösungsraum enger geblieben.
|
|
|
|
Wenn alle betrachteten Lösungen unbefriedigend sind, lohnt die Prüfung, ob eine Randbedingung genauer formuliert werden kann als zunächst verstanden.
|
|
|
|
\subsection{Eigene Arbeit gegenlesen}
|
|
|
|
Die Nebenläufigkeit wurde nicht durch Test, Review oder Fehlerbericht gefunden, sondern durch erneutes Durchgehen des eigenen, fertiggestellten Codes.
|
|
|
|
Der Pull Request war eingereicht. Die Fehlerbehandlung des Umbenennens war geschrieben worden, um Datenverlust zu verhindern — und genau sie verursacht ihn unter Nebenläufigkeit. Ein selbst eingebautes Sicherheitsnetz prüft man nicht ohne Weiteres erneut.
|
|
|
|
Ausschlaggebend war ein Perspektivwechsel: nicht „funktioniert das?", sondern „was passiert, wenn das zweimal gleichzeitig läuft?". Diese Frage ist für jeden verändernden Codepfad einer Anwendung mit mehreren Instanzen zu stellen — sie war beim Schreiben unterblieben, weil der Pfad als seltener Sonderfall galt. Genau diese Einordnung ließ die Prüfung unterbleiben.
|
|
|
|
\subsection{Pull Requests kleiner und sequenziell schneiden}
|
|
|
|
Die in Abschnitt~\ref{sec:code-reviews} beschriebene Ballung war Folge einer bewussten, im Rückblick falschen Entscheidung: Vier gleichzeitig eröffnete Pull Requests sollten Wartezeiten auf Reviews vermeiden.
|
|
|
|
Der erwartete Vorteil trat nicht ein, weil die Arbeiten aufeinander aufbauten: Statt Parallelität entstand eine Warteschlange, deren Auflösung sich in die Woche vor der Abnahme verschob. Die Verkettung der Zielbranches brachte eigene Kosten: Jede Umstellung auf den Hauptbranch setzte Freigaben zurück. Bei abhängigen Aufgaben ist sequenzielles Vorgehen vorzuziehen.
|
|
|
|
\subsection{Konsistenz braucht einen Vergleich, keine Beschreibung}
|
|
|
|
Der einzige Abnahmefehler betrifft eine Anforderung aus mehreren Backlog Items: Die Bedienung soll sich an den übrigen Seiten orientieren.
|
|
|
|
Sie wurde nicht verletzt, weil sie übersehen wurde, sondern weil sie sich nicht aus einer Beschreibung ableiten lässt. Eine Schaltfläche zum Leeren des Suchfelds widerspricht keiner Vorgabe — erst der Vergleich mit den bestehenden Seiten macht die Abweichung sichtbar.
|
|
|
|
Für solche Anforderungen ist ein Abnahmetest durch eine Person, die die Anwendung kennt, unersetzbar — und sollte früher angesetzt werden als hier geschehen.
|
|
|
|
\subsection{Persönliche Einordnung}
|
|
|
|
Gegenüber den vorangegangenen Praktika lag der Schwerpunkt auf Entwurfsentscheidungen. Der Anteil für Recherche, Abwägung und Begründung war erheblich — die sechs Lösungsansätze für den Lookup und die Nebenläufigkeitsanalyse erzeugten keine einzige Zeile ausgelieferten Codes.
|
|
|
|
Zugleich bestimmten diese Anteile den Projektverlauf. Die Erfahrung, dass eine sauber begründete Abgrenzung mehr wert ist als eine schnelle, unvollständige Behebung, ist die wesentliche Erkenntnis dieses Projekts.
|