Engineering-Handwerk · Tag 1: Wartbarer Code

Willkommen zu Tag 1 unserer Serie Engineering-Handwerk. Wir starten mit der unbequemsten Wahrheit unseres Berufs: wartbarer Code sieht im ersten Moment teurer aus, ist über die Lebensdauer eines Systems aber fast immer der günstigere Weg. Das ist keine Meinung, sondern eine Beobachtung aus Jahren, in denen wir fremden Code übernommen, eigenen Code bereut und beides irgendwann in Ordnung gebracht haben. Wer nur den ersten Sprint bezahlt, bezahlt am Ende doppelt.

Das klingt nach einer dieser Weisheiten, die alle nicken lassen und trotzdem niemand befolgt. Genau deshalb machen wir hier keinen Vortrag über Prinzipien, sondern rechnen nach: Woher kommen die versteckten Kosten von schnell hingehauenem Code? Was genau macht wartbaren Code aus? Und wie machst du Wartbarkeit sichtbar, damit sie im Projekt nicht als Erstes wegpriorisiert wird, wenn der Termin drückt?

Worum es in dieser Serie geht

Engineering-Handwerk ist eine Journey. Kein Manifest, keine zehn goldenen Regeln, die du dir an die Wand hängst. Wir gehen die Themen durch, die den Unterschied zwischen einem Projekt machen, das nach zwei Jahren noch weiterentwickelt werden kann, und einem, das dann nur noch mit angezogener Handbremse und Angst angefasst wird. Über die nächsten Tage geht es um Tests, die etwas aussagen, um Grenzen zwischen Modulen, um Reviews, die mehr sind als ein Daumen-hoch, und um den Umgang mit dem Code, den wir alle schon geerbt haben.

Wir fangen mit Wartbarkeit an, weil sie das Fundament ist. Fast jedes andere Thema dieser Serie zahlt am Ende darauf ein. Wenn du verstehst, warum wartbarer Code sich rechnet, verstehst du auch, warum sich der Aufwand für gute Tests und saubere Schnittstellen lohnt.

Was diese Serie nicht ist

Sie ist kein Plädoyer für Perfektionismus. Wir bauen kommerzielle Software, keine Kunstwerke. Es gibt Code, der drei Wochen lebt und dann gelöscht wird, und für den ist eine dreifach abstrahierte Architektur schlicht Verschwendung. Die Kunst ist zu wissen, wann Wartbarkeit sich lohnt und wann sie Selbstzweck wird. Diese Unterscheidung zieht sich durch alles, was folgt.

Warum wartbarer Code kurzfristig teurer wirkt

Wartbarer Code kostet im Moment des Schreibens mehr. Das lässt sich nicht wegdiskutieren, und wer das Gegenteil behauptet, hat entweder nie unter echtem Termindruck geliefert oder verkauft etwas. Du benennst Dinge sorgfältig statt data2 und tmp. Du ziehst eine Funktion auseinander, die eigentlich schon lief. Du schreibst Tests, die im Moment nichts beweisen, was du nicht ohnehin weißt. Du diskutierst im Review über eine Schnittstelle, die man auch einfach hätte durchreichen können.

Jeder dieser Schritte kostet Minuten bis Stunden, und alle davon sind sofort sichtbar. Der Nutzen dagegen ist unsichtbar, weil er in der Zukunft liegt und statistisch verteilt ist: bei der Kollegin, die den Code in acht Monaten erweitert, beim Bug, der wegen einer klaren Grenze gar nicht erst entsteht, bei dem Feature, das dank Tests ohne Angst umgebaut werden kann. Sichtbare Kosten gegen unsichtbaren Nutzen — das ist der Grund, warum Wartbarkeit unter Druck immer als Erstes fällt. Nicht weil Teams dumm sind, sondern weil unser Gehirn das Sofortige überbewertet.

Die versteckten Kosten von „schnell hingehauen“

Schnell hingehauener Code ist selten ein einmaliger Rabatt. Er ist ein Kredit mit Zinseszins. Der Klassiker: Eine Funktion macht drei Dinge gleichzeitig, weil das beim Schreiben am schnellsten ging. Beim ersten Lesen brauchst du zehn Minuten, um sie zu verstehen. Beim zweiten wieder, weil sich niemand alles merkt. Multipliziere das mit jedem Entwickler, der sie je anfassen muss, und mit jeder Änderung, die riskanter ist, weil man nie ganz sicher ist, welchen der drei Zwecke man gerade kaputt macht.

Dazu kommen die Zweitrundeneffekte, die keiner ins Ticket schreibt. Der Bug, der entsteht, weil zwei Module über eine geteilte Variable heimlich gekoppelt waren. Der Feature-Wunsch, der abgelehnt wird — nicht weil er fachlich unsinnig ist, sondern weil ihn niemand im Bestandscode unterbringen will. Die neue Kollegin, die drei Wochen statt drei Tage braucht, bis sie produktiv ist, weil das System nirgends erklärt, wie es gedacht ist. Das sind reale Kosten. Sie stehen nur nirgends auf einer Rechnung, und deshalb tut jeder so, als gäbe es sie nicht.

Unsere Faustregel aus der Praxis: Code wird über seine Lebensdauer deutlich öfter gelesen als geschrieben. Bei langlebigen Systemen ist das Verhältnis nicht knapp, sondern eklatant. Wenn du beim Schreiben zehn Minuten sparst und dafür bei fünfzig Lesevorgängen je zwei Minuten mehr kostest, hast du kein Geschäft gemacht — du hast einen schlechten Tausch als Effizienz verkauft.

Woran du wartbaren Code erkennst

Wartbarkeit ist kein Gefühl, auch wenn erfahrene Entwickler sie oft zuerst als Unbehagen spüren. Sie hat konkrete Merkmale, die man benennen und im Review einfordern kann.

Lesbarkeit

Guter Code liest sich wie eine Erklärung dessen, was er tut, nicht wie ein Rätsel, das man erst dekodieren muss. Namen sagen die Absicht: Eine Funktion heißt nach dem, was sie erreicht, nicht nach dem, wie sie es intern anstellt. Der Ablauf folgt einer Reihenfolge, die ein Mensch erwartet. Es gibt nicht drei Verschachtelungsebenen, wo eine reichen würde. Lesbarkeit ist die günstigste Form der Dokumentation, weil sie nie veraltet — der Code ist immer die Wahrheit.

Klare Grenzen und wenig Kopplung

Ein wartbares System hat Module mit klaren Zuständigkeiten und schmalen Schnittstellen dazwischen. Du kannst einen Teil ändern, ohne den ganzen Rest im Kopf haben zu müssen. Das Gegenteil ist enge Kopplung: Alles hängt an allem, und jede Änderung löst eine Kettenreaktion aus. Der beste Test dafür ist eine ehrliche Frage — wenn ich diese Datei ändere, wie viele andere muss ich anfassen oder wenigstens verstehen? Ist die Antwort „viele“, ist die Kopplung zu hoch, egal wie hübsch der einzelne Code aussieht.

Tests, die Vertrauen schaffen

Tests sind nicht dazu da, eine Coverage-Zahl schön zu machen. Sie sind das Sicherheitsnetz, das Änderungen ohne Angst erlaubt. Ein System mit guten Tests kann umgebaut werden; ein System ohne sie wird mit jedem Jahr starrer, weil niemand mehr weiß, was eine Änderung kaputt macht. Wichtig ist die Aussagekraft: Ein Test, der nur bestätigt, dass die Funktion existiert, ist Ballast. Ein Test, der das fachliche Verhalten an der Grenze prüft — den Sonderfall, die leere Liste, den ungültigen Betrag — ist Gold wert.

Wenig Überraschungen

Wartbarer Code ist langweilig, und das ist ein Kompliment. Er hält sich an die Konventionen des Projekts, macht keine cleveren Tricks, die man erst googeln muss, und tut das, was sein Name verspricht — nicht mehr und nicht weniger. Cleverness ist im Bestandscode ein Kostenfaktor, kein Ausweis von Können. Die wirklich guten Entwickler, die wir kennen, schreiben Code, der so schlicht wirkt, dass man denkt, das hätte man auch selbst so gemacht. Genau das ist die Kunst.

Ein konkretes Beispiel aus der Praxis

Wir haben einmal ein Bestellsystem übernommen, in dem der Versandkostenberechnung eine einzige Funktion zugrunde lag. Diese Funktion las den Warenkorb, ermittelte das Zielland, holte den Lagerbestand, wählte den Versanddienstleister, berechnete die Kosten, schrieb ein Log und aktualisierte nebenbei den Bestellstatus. Rund zweihundert Zeilen, keine Tests, drei ineinander verschachtelte Bedingungsblöcke. Sie lief. Jahrelang. Bis der Kunde in ein weiteres Land liefern wollte.

Die eigentliche Änderung war fachlich winzig: ein neues Land, ein anderer Dienstleister, eine leicht andere Kostenregel. Im vorhandenen Code war sie ein Albtraum. Niemand traute sich, etwas zu ändern, weil dieselbe Funktion auch den Bestellstatus schrieb — ein Fehler dort hätte Bestellungen in einen falschen Zustand versetzt, und es gab keinen Test, der davor gewarnt hätte. Die Schätzung für diese „kleine“ Erweiterung lag bei mehreren Tagen, fast alles davon reines Verstehen und vorsichtiges Antasten, nicht das Schreiben neuer Logik.

Wir haben zuerst die Funktion entkoppelt: Die Statusaktualisierung raus, das Logging raus, die reine Kostenberechnung isoliert. Dann Tests um die bestehende Berechnung geschrieben, damit wir wussten, dass wir beim Umbau nichts verändern, was heute funktioniert. Erst danach kam das neue Land dazu. Das kostete beim ersten Mal mehr, als das Feature „eigentlich“ wert war — offen gesagt fast das Doppelte der ursprünglichen Schätzung. Aber die nächsten beiden Länder, die der Kunde ein halbes Jahr später wollte, waren jeweils eine Sache von Stunden statt Tagen. Ab dem zweiten Mal hatte sich der Einsatz bezahlt, und ab dem dritten war er reiner Gewinn.

Das ist der ganze Punkt in einer Geschichte: Die erste Investition in Wartbarkeit sieht aus wie Verschwendung, weil sie mehr kostet als die konkrete Aufgabe rechtfertigt. Sie rechnet sich erst über die Wiederholung. Aber Software, die überhaupt gepflegt wird, wird fast immer wiederholt angefasst. Deshalb ist der Tausch fast immer richtig.

Wartbarkeit sichtbar und messbar machen

Das Kernproblem bleibt: Wartbarkeit verliert unter Druck, weil ihr Nutzen unsichtbar ist. Der wichtigste Hebel ist deshalb, sie sichtbar zu machen. Man muss sie nicht auf die zweite Nachkommastelle messen — man muss sie aus dem Bauchgefühl in etwas überführen, worüber ein Team gemeinsam entscheiden kann.

Ein paar Signale, die wir tatsächlich nutzen

• Änderungsaufwand statt Codezeilen. Wie lange dauert eine typische kleine Änderung in einem Bereich? Wenn eine triviale Anpassung regelmäßig einen halben Tag frisst, ist das ein handfestes Signal — überzeugender als jede abstrakte Metrik.
• Wie viele Dateien eine Änderung berührt. Muss man für ein kleines Feature an zehn Stellen ran, ist die Kopplung zu hoch. Das lässt sich an den Pull Requests direkt ablesen, ganz ohne Werkzeug.
• Bug-Herkunft. Häufen sich Fehler in denselben Modulen, zeigt das, wo die Struktur nicht trägt. Diese Hotspots sind die ehrlichste Wartbarkeits-Landkarte, die ein Projekt hat.
• Einarbeitungszeit. Wie lange braucht ein neuer Mensch, bis er in einem Bereich sicher etwas ändert? Das ist ein direkter Gradmesser für Verständlichkeit.

Automatische Kennzahlen wie Komplexität pro Funktion oder Testabdeckung sind nützlich, aber nur als Frühwarnung, nie als Ziel. Sobald eine Zahl zum Ziel wird, optimieren Menschen die Zahl statt die Sache dahinter — dann hast du hundert Prozent Coverage aus lauter nichtssagenden Tests. Nimm die Zahlen als Fieberthermometer, nicht als Note.

So gehst du vor

Wenn du Wartbarkeit in deinem Team ernst nehmen willst, ohne in Prinzipien-Diskussionen zu versacken, hilft eine konkrete Reihenfolge:

• Mach die Kosten explizit. Wenn eine Aufgabe teuer ist, weil der Bestandscode im Weg steht, schreib das ins Ticket. Nicht als Vorwurf, sondern als Fakt: „Ein Tag von dreien geht für das Verstehen der bestehenden Funktion drauf.“ So wird technische Schuld aus dem Bauchgefühl zu einer Zahl, über die man reden kann.
• Investiere dort, wo es wehtut. Nicht alles muss wartbar sein. Verbessere gezielt die Hotspots — die Bereiche, die oft geändert werden und oft Fehler produzieren. Code, den niemand anfasst, darf ruhig hässlich bleiben.
• Refaktoriere im Rahmen echter Arbeit. Große isolierte Aufräum-Projekte werden gestrichen, sobald es eng wird. Kleine Verbesserungen, die an ein Feature andocken — erst aufräumen, dann erweitern — überleben, weil sie einen sichtbaren Zweck haben.
• Setz Standards, die entlasten. Ein gemeinsamer Stil, automatische Formatierung, klare Konventionen. Nicht um Kreativität zu ersticken, sondern um sie für die Probleme aufzusparen, die es verdienen. Wenn niemand mehr über Klammern und Einrückung streiten muss, bleibt Kopf frei für die Struktur.
• Nutze Reviews für Wartbarkeit, nicht nur für Korrektheit. Ein Review, das nur fragt „funktioniert es?“, verschenkt seinen größten Wert. Die eigentliche Frage ist: „Wird das jemand in einem Jahr verstehen und gefahrlos ändern können?“ Das ist der Moment, in dem Wartbarkeit tatsächlich entsteht — bevor der Code gemerged wird, nicht danach.

Reviews und Standards verdienen einen eigenen Satz, weil sie der Ort sind, an dem Wartbarkeit zur Teamgewohnheit wird statt zur Einzelleistung. Ein einzelner Entwickler kann sauberen Code schreiben. Aber ein Team, das im Review konsequent nach Lesbarkeit, Grenzen und Testbarkeit fragt, hebt das Niveau für alle — und macht es unabhängig davon, wer gerade tippt. Standards sind dabei kein Käfig, sondern das Gegenteil: Sie nehmen die immer gleichen Kleinentscheidungen ab, damit die Aufmerksamkeit für das Wesentliche bleibt.

Fazit

Wartbarer Code sieht teurer aus, weil seine Kosten sofort und sichtbar anfallen, während sein Nutzen in der Zukunft und im Verborgenen liegt. Über die Lebensdauer eines Systems dreht sich das um: Schnell hingehauener Code sammelt Zinsen, die niemand ins Ticket schreibt, und wartbarer Code zahlt sich mit jeder Wiederholung stärker aus. Der Schlüssel ist nicht Perfektion, sondern Urteilsvermögen — investieren, wo es sich lohnt, und die Kosten sichtbar machen, damit sie unter Druck nicht als Erstes verschwinden. Das ist das Fundament, auf dem die restliche Serie aufbaut.

Das war Tag 1. In den nächsten Episoden vertiefen wir Tests, Schnittstellen und Reviews — jeweils mit demselben pragmatischen Blick. Die gesammelten Folgen findest du in der Serien-Übersicht. Wenn du wartbare Software nicht selbst bauen, sondern bauen lassen willst, sieh dir unsere Softwareentwicklung an oder nimm direkt Kontakt mit uns auf — wir reden lieber über konkrete Systeme als über Prinzipien.