Das Runtimedata-Verzeichnis als Standard für die lokale Entwicklung

Die lokale Entwicklungsumgebung ist der Ort, wo neue Werte, Ideen und Funktionen entstehen, wenn die Developer Experience stimmt, also die Entwicklung leicht von der Hand geht. Eine häufige Aufgabe, die bei der Einrichtung der lokalen Entwicklungsumgebung auftritt, ist die Entscheidung, wo wir temporäre Daten und Dateien ablegen, die bei der Entwicklung und beim Testen entstehen, wenn ein Testsystem aufgesetzt, in ihm getestet oder Integrationstests ausgeführt werden. Gibt es auf diese Frage keine direkte und von allen geteilte Antwort, entstehen Fragen danach, wo etwas abgelegt oder gefunden wird. Wo liegen die Logfiles, mit denen das Verhalten des Systems nachvollzogen werden kann? Wo werden die Dateien für den Datenaustausch hingeschrieben oder von wo können sie geladen werden? Wo soll die PostgreSQL-Datenbank ihre Datafiles ablegen, wenn sie als Docker-Container ausgeführt wird?

In jedem Projekt wird das anders gehandhabt. Ein neues Projekt. Alles anders. Jedes Mal die gleiche Frage. Jedes Mal eine andere Antwort. Oft gibt es auch keine Antwort und dementsprechend steigt die Varianz in dem Projekt und unser Aufwand, um unsere Aufgabe zu vollbringen, wächst.

Wie wäre es mit einem Standard für die Frage: Wo kommen all die Daten und Dateien hin, die wir temporär brauchen, aber nicht unter Versionskontrolle sollen?

Hierfür einen Standard zu haben, zahlt auf zwei wesentliche Punkte in der Software-Entwicklung ein: die Developer Experience und das Prinzip Don’t make me think!.

Developer Experience beschreibt die Gesamtheit aller Erfahrungen, die Entwickler bei ihrer Arbeit machen und umfasst sowohl das soziale Umfeld der Arbeit als auch die technische Ausgestaltung der Arbeitsumgebung. Die Developer Experience ist umso besser, je leichter und angenehmer sich eine Aufgabe umsetzen lässt, unabhängig von der Aufgabe an sich.

Eine positive Developer-Experience trägt positiv zur Wertsicherung und -entwicklung einer Organisation bei.

Don’t make me think! beschreibt den Ansatz, die kognitive Last bei der Erledigung einer Aufgabe zu reduzieren, welche sich nicht direkt aus der Aufgabe selber ergibt.

Die oben gestellte Frage kann einfach offen gelassen und damit im Status Quo belassen werden, durch viele einzelne Regelungen geregelt oder pragmatisch mit einer einfachen Regelung gelöst werden. Die letztere Variante sollte dabei so einfach sein, dass sie in einem einfachen Satz ausgedrückt werden kann:

Das heißt, dass alle Dateien, die wir nur während der lokalen Entwicklung brauchen und niemals unter Versionskontrolle gestellt werden sollen, sich immer unterhalb eines dedizierten Verzeichnisses befinden.

Dieses Verzeichnis hat die folgenden Eigenschaften:

Mit der Einführung dieses Verzeichnisses gibt es einen kanonischen Ort, an dem sich alle eingangs genannten Daten und Dateien ablegen und finden lassen.

Diesen kanonischen Ort zu haben bringt Vorteile, die sich sofort auszahlen:

Wie das in einem realen Projekt aussehen kann, zeigt das folgende Beispiel aus einem meiner aktuellen Projekte.

Das geforderte Verzeichnis runtimedata befindet sich, wie in Listing 1 zu sehen, im Wurzelverzeichnis des Projektverzeichnisses.

Das Listing 2 zeigt, dass sich im Verzeichnis alle temporären Dateien befinden, wie die Logfiles der Services, die Datafiles der Datenbank und ein Readme. Das Readme beschreibt kurz die Natur dieses Verzeichnisses, damit seine Verwendung direkt im Projekt dokumentiert ist.

Der geforderte Ausschluss aus der Versionsverwaltung wird durch zwei weitere Einträge in .gitignore sichergestellt.

Das lokale Entwicklungssetup ist einer der am meisten unterschätzten Orte für Effizienzgewinne in der Entwicklung. Durch eine einfache Regel wie die Festlegung eines kanonischen Ortes für alle temporären Dateien lässt sich die lokale Entwicklung vereinfachen. Ein Punkt weniger, über den wir nachdenken müssen und zu dem wir Entscheidungen treffen müssen, obwohl sie nichts mit der eigentlichen Wertschöpfung zu tun haben, weil wir uns auf sinnvolle und effektive Standards verlassen können. Don’t make me think!