Sand im Code

Eine Geschichte über das Zusammenfegen undokumentierten Codes

In diesem Text gebe ich eine neue Perspektive auf den Übergang von Proof-of-Concept (PoC) zu Produktionssoftware. Speziell in kleinen Teams sind die Ressourcen nicht vorhanden Software umfassend umzugestalten und der eine oder andere PoC landet in Produktion. Ich teile hier meine eigenen kondensierten Erfahrungen und Meinungen aus drei Jahren Projektarbeit. Es ist ein schräges Plädoyer für Clean(er) Code, Test Driven Design, ein bisschen funktionale Programmierung und mal darüber nachzudenken, dass auch andere irgendwann auf deinen Code schauen und mit ihm arbeiten werden.

TL;DR

Wenn du Code übernimmst, der als PoC geplant war, aber nun in Produktion läuft, du in einem Team von maximal drei Menschen daran arbeitest und ihr wenig Zeit habt, dann schlage ich folgende Wege vor:

• Erkennt was die Domäne umfasst und bringt den Code anhand dieser Domänen zu logischen Gefügen zusammen
• Wenn schon kein TDD benutzt wurde, dann entwickelt jetzt Tests. Wahrscheinlich müsst ihr diese Arbeiten an der Technical Debt der Kundin “unterjubeln”, also mit anderen Features und Umbauten zusammen als ein untrennbares Paket anbieten und angehen.
• Software wartbar zu machen bedeutet auch Komplexität zu reduzieren. Kann das große Framework durch eine Library oder die Datenbank durch in-memory Lösungen ersetzt werden
• Lebt den “Mut zum Fehler”: muss der alte Code wirklich direkt aus der Produktion entfernt werden oder kann der neue Teil daneben sauber koexistieren. Hier bietet sich blue-green Deployment an.
• Was sagen deine Kolleg*Innen und die Entwickler*Innen bei den Kund*Innen zu deinem Code: Verstehen sie ihn? Nutzen sie ihn? Können sie ihn verwalten?

Aller Anfang ist schwer

Es war ihr zweiter Tag bei der Palin Icecreme Neu-Ulm GmbH als Software-Beraterin. Gisela war nach dem ersten Tag verwirrt nach Hause gekommen. Zum Glück war die PICEN Firma entspannt und plante ein paar Tage OnBoarding ein, bevor Gisela den Programmcode für die neue Marketing Kampagne erweitern sollte. Jetzt, an ihrem zweiten Tag war sie wieder frisch. Als sie gestern auf dem Spielplatz mit ihren Kindern im Sandkasten saß, hatte sie ihren alten Fachinformatik-Ausbilder Friedrich getroffen. Auf ihre Berichte vom ersten Tag hin hatte er mal wieder erwidert: “Alles was nicht getestet ist, ist kaputt. Alles was nicht automatisiert ist, hält dich nachts wach”. Diese Worte rangen nun in Giselas Ohren, als sie durch die Repositories der PICEN Firma blickte. Wirklich alles zu testen oder zu automatisieren war Unsinn, das war ihr klar. Aber ein Mindestmaß des Codes sollte das schon erfüllen. Was sie hier vor sich sah, war ein Albtraum, bei dem so ziemlich alles kaputt war.

Einen Proof-of-Concept in Produktion zu bringen ist meist mehr Handwerk als Kunstwerk. Gisela war es als Software-Beraterin gewohnt, wertvolle PoC’s für die Kundinnen so auszubauen, dass sie auch den Unwägbarkeiten von Usern und Produktivumgebungen standhalten. Hier hatte sie nun ein Paradebeispiel vor sich, wie es nicht sein sollte. Hier lief ein Programm mit hohem Wert für den Kunden in Produktion, aber das Programm war von der ursprünglichen Entwicklerin Julia nie dafür vorgesehe. Es war lediglich ein PoC, ein Herumspielen, der ein paar wertvolle Hinweise ausspuckte. Nun ja, dachte sie sich, dann mal ran an die Waffeln.

Es war wertlos für PICEN jetzt einfach in monatelanger Feinarbeit Tests zu generieren, eine CI/CD Pipeline aufzusetzen, Doku zu schreiben und Recovery Mechanismen einzubauen. Aber irgendwie musste Gisela PICEN klar machen, dass die neue Marketingkampagne sich nicht leicht in das Programm einarbeiten ließ. Was ist für PICEN wertvoll, was wertlos? Welche Anforderungen an Wartung und Verständlichkeit hatte PICEN an dieses Programm? Oder sollte der PoC einfach weggeworfen und neu gebaut werden? Dieses Gespräch hatte sie auch gestern mit Friedrich am Spielkasten geführt. Denn am Ende geht es ums wesentliche: Was braucht die Kundin, nicht was ist schick und hipp? Wie auf dem Spielplatz: der beste Spielplatz ist unnütz, wenn die Kinder nicht gern dort spielen. Also konzentrieren wir uns auf das was Wert schafft. Was auch immer PICEN darunter eben versteht.

Der PoC läuft in Prod

Am dritten Tag kam beim Stand-Up Daily schnell Klarheit in die Sache. Julia war für kurze präzise Sprints eingestellt, um zu zeigen, wie mit einem Microservice die PICEN Marketingabteilung schnell Kundenversuche machen konnte. Die Marketingabteilung wollte wissen, welche neuen Geschmacksrichtungen gut bei den Endkund*Innen ankamen. Das war als PoC aufgesetzt worden und dann musste Julia schon weiter, das Projekt war zu Ende. Das Programm lief weiter und die Endnutzer*Innen waren zufrieden. Bis es neue Ideen gab. An dieser Stelle kam nun Gisela ins Spiel, sie sollte diese neuen Ideen in den bestehenden Code hinzufügen.

Code in Produktion sollte hoch verfügbar und wartbar sein, außerdem leicht erweitert werden können. Auch für PICEN waren das wichtige Anforderungen. Diese Anforderungen spiegeln sich auch im Code wieder, der hier vor Gisela lag. Nur leider war nicht klar, warum gewisse Entscheidungen anhand der Anforderungen getroffen wurden. Julia hatte wegen des PoC Charakters wenig dokumentiert und keinen einzigen Test geschrieben. Für einen PoC, der in ein, zwei Tagen geschrieben wurde ist das auch ganz in Ordnung. Aber teilweise war Gisela gar nicht klar, warum gewisse Tools oder Datenbanken in den Repositories vorkommen. Überhaupt – warum gab es drei Repositories für den PoC? Die leider ungenügende Dokumentation lag in einem eigenen Repository, der Programmcode in einem anderen und im dritten lagen die Skripte um alles zusammenzubauen. Nun ja, das ließ sich zügig mit der entsprechenden Ordnerstrukturen und Anpassungen in der Docker Compose File lösen und zusammenbringen.

Was PICEN aber nun wollte, sollte möglichst gestern stehen. Refactoring musste erstmal warten, es ging darum zügig die neuen Marketing Ideen umzusetzen. Mit einer Dev-Umgebung baugleich zur Produktivumgebung ließ sich das leicht verproben. Die CI/CD Pipeline war auch leicht für das konsolidierte Repository erstellen. Statt wie bisher auf der Produktionsmaschine händisch den Code lokal zu bauen und zu starten brauchte Gisela nur eine Zeile und schon wurden die aktuellsten Images gezogen. Dieser letzte Schritt war zwar händisch, aber vorerst ok. Die Erstellung der Datenbank machte Probleme, da es keine Automatisierung zur Erstellung der entsprechenden Tabellen gab, aber da diese nur für alleinstehende Teile des Programmes benötigt wurde, konnte Gisela diese auch vorerst ignorieren.

Der zentrale Endpunkt für die Marketingkampagne war schnell erstellt, mit logischer Abdeckung getestet und auch im Frontend entsprechend hinterlegt. Gisela konfigurierte das  Frontend über ein einziges Flag so, dass es bestimmte Endpunkte entweder von der Produktiv- oder der Entwicklungsumgebung abrief. Diese Art des blue-green deployments ermöglichte ihr Schritt für Schritt den kaputten Horror-Code in Produktion durch getesteten Code in der Entwicklungsumgebung auszutauschen. Bisher waren die verschiedenen Endpunkte so eng verwoben, dass sich keiner alleinstehend testen ließ. Diese unnötige Komplexität schrie regelrecht nach unerwarteten Fehlern und Problemen beim Refactoring und der Erweiterung für neue Marketingkampagnen.

Innerhalb weniger Tage hatte Gisela eine kleine Anwendung gemacht, die leicht auslieferbar und schon teilweise wartbar war. Das gute daran: PICEN sah ein Ergebnis für die Marketing-Kampagne und das Programm lief stabiler. Selbst die internen Entwickler*Innen von PICEN gaben zu, dass sie sich bisher an das Programm nicht getraut hatten, sich nun aber wohl damit fühlten. In Absprache mit PICEN’s PO sollte das alte Programm mit Methoden des Lean Management einzeln abgeklopft werden: generierten die einzelnen Abschnitte nachhaltig Wert für die Endnutzer*innen, dann wurde er aufgeräumt und entsprechend getestet. Wenn nicht, dann wurde der entsprechende Code gelöscht. Das war ja kein Verlust, da das System vorläufig noch in Produktion lief.

Die Archäologie des Codes

Es war spannend für Gisela zu sehen, welche Entscheidungen Julia getroffen hatte. Ihr war leider nicht ganz klar, woher diese Entscheidungen kamen, aber ihre Folgen waren spürbar. Julia hatte beispielsweise ein Framework für einen Message Broker nochmals gewrapped, wahrscheinlich um den Code kürzer und lesbarer zu machen. Den Mehraufwand rechtfertigte das Wrapping im jetzigen Stadium jedoch nicht. Es wirkte zwar so, als hätte Julia an vielen Stellen gemäß eines PoC’s den Mut zur Lücke bewiesen, aber bei diesem Wrapping dann doch technikbegeistert etwas mehr als dringend notwendig gemacht.

Das schöne am Refactoring fremden Codes für Gisela: es war wie Archäologie. Wie die Kinder auf dem Spielplatz und Archäolog*Innen im fernen Ägypten grub auch sie sich ein in eine Welt, die nicht immer alle ihre Geheimnisse preisgeben wollte. Warum wurde eine MySQL Datenbank verwendet, obwohl die dort abgelegten Daten einmal pro Stunde neu generiert wurden? Eine In-Memory Datenbank hätte doch ausgereicht? Und warum wurde die Datenbank direkt in der Produktivumgebung händisch provisioniert, ohne das irgendwo SQL Befehle oder entsprechende Codes vorlagen? Was hatte Julia mit den vielen Repositories im Schilde und wieso gab es kein automatisches Styling oder Linting? Gisela fand es schade, dass es von PICEN nicht gern gesehen wurde, wenn sie Kontakt zu früheren Entwickler*Innen zur Klärung aufnahmen.

Nichtsdestotrotz, dank des Fokus auf Wert, Lean Methoden, der Schritt für Schritt Überführung von ungetestet zu getestet, der CI/CD Pipeline und der Konsolidierung des Microservice ließ dieser sich nun in Produktion warten. Erweiterungen waren leicht möglich und im nächsten Schritt die Bauteile widerstandsfähig zu machen gut möglich. Durch das blue-green deployment konnte der PoC in Produktion schrittweise ersetzt und erweitert werden, ohne die gesamte Produktion anzuhalten. Davon bemerkte PICEN recht wenig, die Marketingkampagne ging zügig an den Start. PICEN war zufrieden und Gisela hatte Wert generiert. Wieder ein Projekt, das schwierig begann und doch erfolgreich war.