Kein Code, kein System, keine Infrastruktur, nur das Wort.
Bevor jegliches System, komplexe Zusammenarbeit oder auch nur eine einzige Zeile Code existieren kann, muss es Worte geben. Die Sprache ist eine der ersten Abstraktionsschichten, die der Mensch jemals entwickelt hat. Während frühe Höhlenmalereien ebenfalls ein Abbild der derzeitigen Realität darstellen, lassen sie doch deutlich mehr Spielraum für kreative Interpretationen. Das Wort hingegen ist der zentrale Mechanismus, mit dem wir Struktur bringen können in die sonst so unbändige, chaotische Welt.
Auch die Softwareentwicklung hat über die Jahrzehnte immer weitere Abstraktionsschichten aufgebaut – von höheren Programmiersprachen bis hin zu grafischen Benutzeroberflächen. Und damit werden aus geschriebenen Worten und der festen Struktur, die uns die Sprache gibt, nur noch ein paar Mausklicks in den bunten Bedienoberflächen einer Vielzahl von Tools. Böse Zungen schimpfen diese Ansätze "Klickie-Buntie" oder "Klick-Ops". Natürlich haben grafische Oberflächen ihre Berechtigung. Sie erleichtern den Einstieg, helfen beim Erkunden neuer Systeme und ermöglichen schnelle erste Ergebnisse. Doch genau diese vermeintlichen Vorteile können langfristig zu einem Problem führen: Anstatt Gedanken und Handlungen für sich selbst und Kolleg*innen festzuhalten und Wissen in schriftlicher Form weiterzugeben, gehen Entwickler*innen einen großen Schritt zurück. Wie in grauer Vorzeit streifen sie einsam durch die Plattform-Landschaften und hinterlassen so wenige Spuren wie möglich.
Die Rückkehr zum Chaos
Was hab ich da nochmal gemacht?
Also bei mir funktioniert's.
Frag mal <Kollege X>, der hat da irgendwann mal dran gebastelt.
Ups. Wie und wo machen wir das jetzt rückgängig?
Das ist nur eine kleine Auswahl von Sätzen, die auch Du vielleicht selbst schon einmal gehört oder gesagt hast. Man könnte jetzt vermuten, dass derlei Probleme ganz normal sind, ja sogar unvermeidbar. Ich behaupte allerdings, dass die meisten dieser Probleme aus dem selbst geschaffenen Chaos resultieren. Jenem Chaos, das Methoden mit sich bringt, die zunächst einfach und effizient erscheinen, auf Dauer jedoch die folgenden Situationen verursachen. Eine komplexe Konfiguration kann in der UI schnell zusammengeklickt werden. Doch warum bestimmte Entscheidungen getroffen wurden, können in den meisten Fällen selbst deren Urheber nur wenige Wochen später nicht mehr erklären. Dokumentation und Code laufen auseinander, Fehler werden durch Trial and Error in der UI behoben und die Durchsetzung von Richtlinien wird dem guten Willen der Entwickler*innen anvertraut, anstatt Gesetz zu sein – von der Sicherheit fangen wir hier gar nicht erst an. All der schöne Fortschritt, der uns befähigt hat, unsere Gedanken in Worte zu fassen, wird ignoriert, weil bunte Bildchen und Bequemlichkeit uns mit Quick Wins Stück für Stück ins Chaos zurückstürzen lassen. Wie können wir aus dieser misslichen Lage erlöst werden? In diesem Fall können wir uns leider nur selbst helfen.
X as Code: Die Umkehr zur Ordnung
X as Code oder Everything as Code beschreibt die Philosophie, sämtliche Ressourcen in der Softwareentwicklung in fest strukturiertem Text zu definieren. Dies umfasst nicht nur den klassischen Programmcode, sondern auch Dokumentation, Infrastruktur, Richtlinien, Entwicklungsumgebungen usw. – je mehr, desto besser. Diese Arbeitsweise kann es uns ermöglichen, diese Vielzahl an verschiedenen Ressourcen mit den altbewährten Methoden der Softwareentwicklung einheitlich zu verwalten. Dazu zählen unter anderem Versionierung, Reviews, Automatisierung (CI/CD) und Testing. Richtig angewandt, können diese Konzepte, die wir bei pentacor als Best Practices betrachten, die Qualität unserer Arbeit erheblich verbessern. Durch die konsequente Anwendung dieser Prinzipien können wir dem Chaos entfliehen und die Welt um uns herum neu aufbauen. Plötzlich wird die Dokumentation genauso gereviewt wie der Programmcode selbst, Coding-Richtlinien werden automatisch durchgesetzt, die Infrastruktur ist versioniert und selbst die berüchtigten “Works-on-my-Machine“-Probleme werden auf ein Minimum reduziert. Ganz nebenbei lassen sich textbasierte Konfigurationen auch sehr gut generieren und sind damit deutlich besser für KI-basierte Workflows geeignet als andere Ansätze.
Der Entwickler als Autor
Auf dem Abstraktionslevel, auf dem die meisten Entwickler heutzutage arbeiten – ausgenommen sei hier die hardwarenahe Programmierung –, sind wir kaum noch von klassischen Autoren zu unterscheiden. Entwickler*innen implementieren nicht einfach nur Features, sie erschaffen ganze Systeme aus dem Nichts, nur mit ihren (geschriebenen) Worten. Das Gefühl, wenn nach langer, harter Arbeit etwas Großartiges endlich einfach funktioniert, ist demzufolge beinahe göttlich. Die andere Seite der Medaille betrachten wir hier bewusst nicht. Ich möchte diesen Einstiegsartikel in unsere tägliche Schöpfungsgeschichte daher mit einer Referenz auf eine meiner Lieblingsserien beenden: Supernatural. Wer diese kennt, erinnert sich vielleicht daran, dass Gott darin als ein Autor dargestellt wird, der mit seinem Wort die ganze Welt lenkt. Mit diesem Selbstverständnis und etwas Demut können auch wir Entwickler*innen unsere kleine Welt nach unserem Bild schaffen.
In der folgenden als Serie angelegten Reihe von einzelnen Blogartikeln werden wir Pentacornesen daher zu Autor*innen im klassischen Sinne. An konkreten, praktischen Beispielen stellen wir vor, wie wir die Ressourcen in unseren Projekten mit X-as-Code-Prinzipien entwickeln.
