Wochenrückblick KW 25

Die Macht des Pair-Programmings

In dieser Woche gab es einen besonders produktiven Tag. Voraus ging dem ein Daily, in dem ich um Hilfe bat, für einen komplexen Workflow zischen Frontend und Backend (weiter unten stehen dazu ein paar Details). Zum Start haben wir das Tagesziel besprochen, danach die IDE hochgefahren und eine gemeinsame Session gestartet. (Diesmal mit WebStorm und es lief nicht reibungslos. WebStorm ist im Laufe der Zeit immer unzuverlässiger und instablier geworden).

Die gemeinsame Diskussion, wie wir die Lösung anpacken, hat zu einer besseren Lösung geführt, als ich sie alleine hätte entwickeln können. Die gemeinsame Umsetzung war nicht zwangsläufig langsamer, weil wir uns parallel dem Frontend und Backend zugewandt haben, um danach funktionierende Teile zusammenzustecken.

Im Ergebnis beherrschen beide Entwickler den gesamten Flow, verstehen die Entscheidungen, wie es zu der Lösung gekommen ist, und können im Problemfall gezielt nach der Ursache suchen oder wenn es neue Features gibt, deren Machbarkeit und Aufwand beurteilen – weil der gesamte Stack verstanden ist. Insbesondere letzter Aspekt ist ein verkannter Nutzen von Pair-Programming. Das geteilte Wissen über die Applikation spart nachträglich viel Zeit. Denn bekanntlich lesen wir Code deutlich häufiger, als dass wir ihn schreiben.

Asynchroner Workflow mit Server-Side-Events

Im Rahmen des aktuellen Projekts für die Patientendokumentation haben wir uns damals bei der backend-gesteuerten Aktualisierung des Dashboards für Server-Side-Events entschieden. Bei unserem neuen Feature konnten wir uns diese Entscheidung zunutze machen. Die aktuelle Herausforderung sah wie folgt aus:

• Ein Patient wird entweder in der Detailansicht als verstorben markiert oder ein Rezept wird mit der Begründung "Patient verstorben" abgebrochen.
• Das Ergebnis ist in beiden Fällen identisch: Der Patient soll markiert werden, die laufenden Rezepte je nach Zustand behandelt und ein Arztbericht erstellt werden.
• Während des Prozesses soll dem Anwender ein Fortschrittsindikator in Form eines Kreisels angezeigt werden.
• Sobald der Prozess im Backend fertig ist, soll im Frontend der Kreisel ausgeblendet und eine Benachrichtigung über Erfolg oder Misserfolg erscheinen.

Bei der Pair-Programming-Session ging es darum, den Kreisel anzuzeigen und durch das Backend gesteuert wieder auszublenden. Das Ausblenden wollten wir mittels Server-Side-Events umsetzen. Dabei galt es zu berücksichtigen, dass zwei Anwender gleichzeitig an einem unterschiedlichen Patienten aktiv sein können. Da Server-Side-Events immer an alle aktiven Frontendapplikationen kommunizieren, musste dieser Fall gesondert berücksichtigt werden.

Es gab noch ein paar Fallstricke mehr, die wir unterwegs durch unsere Diskussionen erkannt und gelöst haben. Es ist in der Programmierung stets so, dass der Happy Path 20 % des Aufwands ausmacht und damit 80 % des Features umgesetzt sind. Für die Grenz- und Extremfälle ist es genau andersherum – 80 % des Aufwands für 20 % der Funktion.

Dieser Aspekt macht Prototypen, die den Happy Path validieren und schon komplett fertig aussehen, für Business so schwer greifbar, dass für den Produktiveinsatz noch so viel Zeit und Geld hineinfließen müssen. Aber das ist eine ganz andere Geschichte.

Neuer Fokus im Sportprogramm

Die eingeschränkte Beweglichkeit schlägt sich auf mein Tischtennisspiel nieder. Dank schmerzfreier Schulter habe ich langsam mit Training begonnen. Und die Auswirkungen sind dramatisch und machen mir zu schaffen. Jammern bringt nichts. Also müssen Taten her: Ich habe das Laufen auf einmal pro Woche reduziert, um meinen Level zu halten und dafür mehr auf Kraft und Mobilität geachtet

• Montag Tischtennis + Yoga
• Dienstag Yoga
• Mittwoch Tischtennis + Yoga
• Donnerstag Yoga
• Freitag Tischtennis
• Samstag Gartenarbeit 🥵
• Sonntag 17 km Laufen

Wenn du möchtest, folge mir auf Strava.