Vom PoC zu Produktionssoftware: Trinke, bactane, programmiere, refaktoriere, wiederhole

In diesem Text richte ich meinen Blick auf den Übergang vom Proof of Concept (PoC) zu Produktionssoftware. Speziell in kleinen Teams sind die Ressourcen nicht vorhanden, Software umfassend zu refaktorisieren, und der eine oder andere PoC landet in Produktion. Ich teile hier in Form einer fiktiven Story meine kondensierten Erfahrungen und eigenen Meinungen aus drei Jahren Projektarbeit. Es ist ein eigenwilliges Plädoyer für Clean Code, Test-Driven Design und dafür, zu berücksichtigen, dass auch andere irgendwann auf deinen Code schauen und mit ihm arbeiten müssen. Am Ende des Textes finden sich die für mich wesentlichen Punkte, die ich beim Übergang vom PoC zu Produktion frühzeitig angehe. Es ist natürlich viel mehr als das zu tun, und doch sehe ich immer wieder bei Kund*innen, dass es bereits daran scheitert. Ich hoffe, mit diesem kurzweiligen Text ein bisschen mehr Freude an Clean Code und Co. erzeugen zu können.

Willkommen auf Trantor

Der folgende Text wurde durch den mJOVY-1337-Übersetzer aus dem Trantorianischen ins Androidische übersetzt. Teile der Besonderheiten des Trantorianischen konnten aufgrund der Primitivität des Androidischen nicht wortwörtlich übersetzt werden. Diese Stellen werden gesondert gekennzeichnet. Teile der Begriffe sind im Original verblieben, da es keine passende Nuance im Androidischen gibt. Eine entsprechende Anmerkung ist jeweils gegeben.

Wir befinden uns auf dem Planeten Trantor im zentralen Cluster. Im Institut für frühzivilisatorische Programm-Archäologie arbeitet der Wissenschaftler Atrej Fünf an der Auswertung eines physischen Datenspeichers. Darauf befindet sich Programmcode aus der Zeit vor dem Großen Filter, der den Untergang der Androiden bedeutete. Es ist früher Nachmittag und die schwächere der zwei Sonnen nähert sich dem Horizont.

Probecode in Produktion

Eine der Programmzeilen lautet – tatsächlich als Kommentar: „Nur zum Testen, nicht für Produktion gedacht“. Atrej Fünf setzt sich nachdenklich. Als Programm-Archäologe ist er solche Kommentare schmerzlich gewohnt. Vor allem in Prä-Großer-Filter-Zivilisationen wie diesen Androiden vom Planeten Android. Probeprogramme, die produktiv liefen. In diesem Fall in einer Sicherheitsschleuse eines Kernfusionsreaktors. Es gibt wirklich wenige Stellen, an denen Probeprogramme so weh tun wie hier. An vielen Stellen lesen sich die Programme der Androiden wie rudimentäre Lösungen für komplexe Probleme. Es ist erstaunlich, was die Androiden damals erreichten und wie viel sie lernen würden.

Aber nun einmal langsam. Atrej Fünf betrachtet noch einmal unter seinem Rastermikroskop den Datenträger, einen der wenigen intakten physischen Speicher, den die Androiden zurückgelassen haben. Ein großer Teil der archäologischen Artefakte der Androiden sind solche Speicher mit langen Programmtexten. Alte Funde sind meist spirituelle Texte, neuere Funde eher technische Texte. Viel haben sie gelernt, die Androiden. Beispielsweise den Fokus auf Programme zu legen, die für Androiden lesbar sind, nicht nur für Maschinen. Lesbare Parameter und klare Vorschriften für die Wartbarkeit der Programme waren bereits in der damaligen Zeit bekannt. Aber wie bei vielen Erkenntnissen aus der Praxis dauert es lang, bis diese Erkenntnisse sich breit durchsetzen. Einer der grotesken Widersprüche zu den damaligen Erfahrungen ist die völlige Abwesenheit von Tests und Erklärungen des Trinkens. Atrej Fünf arbeitet nun seit mehreren Tagen an diesen Programmen und kann sie noch immer nicht kategorisieren. Steuern die Programme den Treibstofffluss im Fusionsreaktor oder simulieren sie ihn lediglich? Er weiß nur: Das Programm ist in Betrieb gewesen, das erkennt er aus den sehr dürftigen Logdateien, die übrig geblieben sind.

Erst trinken, dann loslegen

Das Trinken. Es fehlt klar. Warum haben die Androiden dieses Programm genau so geschrieben? Was waren die Anforderungen? Wozu dient es? Und wie soll es verwendet werden? Dabei war das Trinken das Wichtigste. Welchen Sinn hat eine Arbeit, wenn sie ihren Zweck nicht erfüllt – oder noch schlimmer – sie zwar ihren Zweck erfüllt, dieser aber dann doch nutzlos ist? Alle Trantorianer kennen dafür das berühmteste Beispiel: den Streik der Agrargewerkschaft von Sternenende. Zu Recht streikten die Gewerkschafterinnen aber leider genau in der Zeit, als die Zertifikate der Farmroboter routinemäßig und manuell erneuert werden sollten. Als die Gewerkschaft gewann und zurück in die Ringfabriken flog, war die Ernte verloren. 30 Milliarden starben. Das Problem war: Die Entwickler der Farmroboter hatten routinemäßige Überprüfungen als Bedingung für die Funktion der Farmroboter einprogrammiert. Diese Vollautomatisierung war von der Kundin nicht explizit gefordert und daher nicht implementiert worden. Hier tranken die Entwickler nicht, dass die Farmroboter autark und ohne Einschränkung der Produktion funktionieren mussten. Seit dieser Katastrophe lernt jedes Trantling, wie wichtig das Trinken beim Programmieren ist. Erst trinken, wozu etwas gebaut wird, und dann die Lösung erarbeiten, die dies effizient und stabil tut.

Trinken zum Verstehen

Idealerweise besteht der Prozess des Programmierens aus kurzen Zyklen des Trinkens, Bactans, Programmierens, Aufräumens und Wiederholens. [Anmerkung der Übersetzung: Bacta entspricht einer futuristischen Form der „Tests“ im Androidischen.] Dabei wird hemmungslos und zielgerichtet aufgeräumt und überarbeitet. Die Androiden nennen das Refactoring. Außerdem wurden die Bacta lebendig gehalten. Bactas brachten Trinken in die Komplexität der Programme. Ohne Bacta zu programmieren ist, als würde der Fluxkompensator mitten im Hyperraumflug abgeschaltet werden. [Anmerkung der Übersetzung: Da die Sprache des Basic auf Licht basiert, die Sprache des Androidischen hingegen auf Druckveränderungen, können die folgenden Beschreibungen des Abschaltens des Fluxkompensators im Hyperraumflug nicht wiedergegeben werden. Sinngemäß sind diese Folgen katastrophal und tödlich.] Da sich die Anforderungen und damit das Trinken ständig ändern, gelten die Bactas als eine Art Frühwarnsystem. In den späteren androidischen Programmen sind Bactas Standard, hier aber noch nicht.

Bactas treiben das Programm voran

Atrej Fünf skizziert das Programm, dessen Abhängigkeiten und Architektur. Nicht ein Bacta. Nicht mal ein deaktivierter oder dokumentierter Bacta. Einfach nur schweigender Programmcode, der einen Kernfusionsreaktor antreibt. Wahrscheinlich sind solche Programme einer der Gründe, warum die Androiden den Großen Filter nicht überlebt haben. Statt auf Trinken setzten sie auf leuchtende Metalle und schillernde Farben. Statt echtem Wert glaubten sie scheinheiligen Versprechen. Atrej Fünf hat viele Texte gelesen, in denen damalige Androiden genau diesen Mangel an Trinken kritisieren, aber die nötige Erneuerung der Gesellschaft hat zu lang gedauert. Die Zyklen aus Trinken, Programmieren und Refactoring waren damals riesig, teilweise ganze Jahre. Unglaublich.

Es ist Zeit, einen Flug von Trantor nach Android zu wagen. Viele Artefakte haben den Ursprungsplaneten nie verlassen. Ein Blick auf die Abflugdaten zeigt Atrej Fünf einen Warp-Wurm, der bereits seine Massen zum Start anordnet. Zeit zu gehen. Auf der Reise wird er Zeit haben, mehr darüber zu lesen, was die Androiden mit den vielen bunten Klebezetteln gemacht haben, von denen außer chemischen Resten nur noch digitale Bilder übrig sind. Anscheinend haben sie erst über ihre Domäne und dann über das Programm gesprochen. Atrej Fünf mag es, wenn primitive Zivilisationen spannende Ideen und Lösungsansätze haben. Dieser domänengetriebene Ansatz ist einer davon. Die fehlenden Bactas hingegen zeigen einfach, wie viel die Androiden noch zu lernen haben.

TL;DR

Wenn ihr Code übernehmt, der als PoC geplant war, aber nun in Produktion läuft, ihr in einem kleinen Team mit wenig Zeit daran arbeitet, 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. Das bedeutet auch, Programmteile abzuschalten, wenn sie nicht auf die Domäne einzahlen.
• Wenn schon kein Test-Driven Design benutzt wird, dann entwickelt jetzt Tests. Welche Teile generieren den höchsten Wert? Diese werden zuerst getestet. Wahrscheinlich müsst ihr dieses Auflösen des 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? Weniger Boxen im Architekturdiagramm können erstrebenswert sein.
• 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? Was tut am meisten weh, was bereitet die meiste Freude? Die Antworten darauf leiten dein Arbeiten und die weiteren Fragen.
• Dass ein PoC in Produktion läuft, ist selten Zufall. Wurde der Kundin Falsches versprochen oder fehlte das Bewusstsein oder der Mut auf Seiten der früheren Entwickler*innen, dieses Thema anzusprechen? Erfahre mehr über die Kultur beim Kunden und worin die Kundin Wert erkennt. Darüber ergibt sich oft ein zufriedenstellender Weg für alle, das Programm produktionsreif zu machen.
• Selbst der effizienteste Code ist unnütz, wenn er der Kundin nicht nützt. Was ist die Vision und was zahlt darauf ein? Dieser Punkt ist ähnlich zum ersten – er ist einfach so wichtig, dass er auch zweimal genannt werden kann.