Niemand versteht unseren Code mehr: Wie Codebasen unwartbar werden

Jedes Unternehmen mit Software, die alt genug ist, um relevant zu sein, führt irgendwann dasselbe Gespräch. Jemand bittet um eine kleine Änderung, und die Antwort kommt langsamer als erwartet, meist mit der Warnung, dass niemand ganz sicher ist, was sonst noch kaputtgehen könnte. Dieses Zögern ist das klarste Zeichen einer unwartbaren Codebasis, und es entsteht fast nie auf einmal. Es baut sich über Jahre auf, eine vernünftige Entscheidung nach der anderen, bis ein Entwickler eines Tages eine Datei öffnet, sie zweimal liest und fragt, wer das geschrieben hat und warum.

Oft ist die ehrliche Antwort: jemand, der vor zwei Jahren gegangen ist, unter einer Deadline, an die sich niemand mehr erinnert, aus einem Grund, der damals sinnvoll war.

Was „niemand versteht den Code mehr" wirklich bedeutet

Wenn ein nicht-technischer Geschäftsführer hört, dass sein System zu Legacy-Code geworden ist, kann das wie eine Beleidigung gegenüber dem ursprünglichen Entwickler klingen. Das ist es in der Regel nicht. Legacy-Code bedeutet im alltäglichen Sinn, wie ihn die meisten Entwickler verwenden, einfach Code, der noch in Produktion läuft, den das aktuelle Team aber nicht mehr sicher ändern kann. Die Person, die ihn geschrieben hat, war vielleicht ausgezeichnet. Der Code war für das damalige Problem vielleicht exakt richtig. Verändert hat sich alles drumherum: das Team, die Geschäftsregeln, die Anzahl der Kunden, die darauf angewiesen sind, dass er korrekt funktioniert.

Eine Codebasis wird unwartbar, wenn der Aufwand, sie zu verstehen, den Aufwand übersteigt, für eine bestimmte Änderung, selbst eine kleine, neuen Code von Grund auf zu schreiben. Das ist die praktische Definition, die man sich merken sollte, weil sie direkt auf die Lösung hinweist. Das Problem ist nicht, dass der Code alt ist. Viele zehn Jahre alte Systeme sind völlig gesund. Das Problem ist, dass derzeit niemand im Team das Verhalten des Systems gut genug im Kopf behalten kann, um es sicher zu ändern.

Wie eine Codebasis an diesen Punkt kommt

Niemand setzt sich das Ziel, etwas Unwartbares zu bauen. Es entsteht durch eine lange Reihe von Entscheidungen, die für sich genommen jeweils nachvollziehbar waren.

Ein Feature geht zwei Wochen vor einer Messe live, und das Team einigt sich darauf, es später aufzuräumen. Später kommt nie ganz, weil immer schon die nächste Deadline wartet. Ein Entwickler, der die Abrechnungslogik verstanden hat, verlässt das Unternehmen, und die Dokumentation, die er eigentlich schreiben wollte, bleibt eine halbfertige Seite in einem Wiki, das niemand mehr öffnet. Eine neue Kraft, die mit dem ursprünglichen Design nicht vertraut ist, fügt neben einer Logik, der sie nicht ganz traut, lieber einen Workaround ein, statt das Risiko einzugehen, etwas kaputt zu machen. Multiplizieren Sie dieses Muster über drei oder vier Jahre und ein Dutzend Mitwirkende, und Sie erhalten ein System, in dem in jeder Datei die Instinkte eines etwas anderen Autors stecken, ohne dass eine einzige Person sich noch erinnert, warum ein bestimmtes Teil so funktioniert, wie es funktioniert.

Tests spielen hier eine größere Rolle, als den meisten Geschäftsführern bewusst ist. Ein Team mit solider automatisierter Testabdeckung kann Code mit einer gewissen Sicherheit ändern, weil die Tests die meisten Fehler abfangen, bevor ein Kunde sie findet. Ein Team ohne Tests fliegt nach Gefühl, und das Fliegen nach Gefühl wird mit jedem weiteren Monat langsamer und riskanter. Fehlende Tests sind selten das Ergebnis von Faulheit. Meist sind sie das Ergebnis desselben Deadline-Drucks, der schon die schnellen Korrekturen hervorgebracht hat: Tests zu schreiben braucht Zeit, und das nächste Release wartet nicht.

Lücken in der Zuständigkeit verschärfen das alles noch. War ein Freelancer oder ein ausgeschiedener Mitarbeiter die einzige Person, die einen bestimmten Teil des Systems verstanden hat, verschwindet dieses Wissen einfach mit ihr. Niemand hat die Dokumentation aus Nachlässigkeit versäumt. Die Dokumentation verliert fast immer gegen die nächste dringende Aufgabe, bis zu dem Tag, an dem sie jemand braucht und sie nicht da ist.

Was eine unwartbare Codebasis wirklich kostet

Die Kosten zeigen sich an Stellen, die selten mit dem Code selbst in Verbindung gebracht werden.

Zuerst verlangsamt sich die Auslieferung von Features. Eine Aufgabe, die drei Tage dauern sollte, dauert drei Wochen, weil jede Änderung zunächst erfordert, herauszufinden, was der bestehende Code tut, bevor man sicher etwas hinzufügen kann. Fehler brauchen aus demselben Grund länger zur Behebung: Ein einzeiliger Patch erfordert einen Nachmittag Recherche, nur um die richtige Zeile zu finden.

Die Personalgewinnung wird schwerer. Erfahrene Entwickler erkennen meist innerhalb der ersten Woche, ob eine Codebasis gesund ist oder nicht, und ein unübersichtliches, undokumentiertes System ist ein echter Grund, warum gute Kandidaten innerhalb der ersten Monate wieder gehen. Sie zu ersetzen, kostet mehr als das Gehalt, das sie bekommen haben.

Das Sicherheitsrisiko wächst leise. In Code, den niemand vollständig versteht, verstecken sich Schwachstellen am längsten, weil sich niemand sicher genug fühlt, ihn gründlich zu überprüfen oder ohne umfangreiche manuelle Tests zu ändern.

Und das Geschäft selbst wird langsamer. Preisänderungen, neue Integrationen, Compliance-Anforderungen: All das hängt davon ab, dass ein Team die Software anfassen und dem Ergebnis vertrauen kann. Fehlt dieses Vertrauen, wird jede Roadmap-Entscheidung still und leise konservativer, als sie sein sollte, nicht weil die Idee schlecht ist, sondern weil niemand derjenige sein will, der die Produktion zum Absturz bringt.

Anzeichen, dass Sie bereits dort sind

Ein paar Fragen bringen das Problem meist schneller zutage als ein formelles Audit. Kann aktuell jemand im Team erklären, ohne vorher den Code zu lesen, wie das Abonnement eines Kunden verlängert oder gekündigt wird? Dauert eine einfache Änderung regelmäßig tagelang länger als nötig, ohne klaren technischen Grund? Gibt es einen Teil des Systems, den alle still meiden, den einen Bereich, bei dem sogar erfahrene Entwickler jemand anderen bitten, das Ticket zu übernehmen? Hat schon einmal eine neue Kraft innerhalb des ersten Monats gesagt, dass sie Angst hat, eine Änderung auszurollen, weil sie nicht versteht, was diese beeinflussen könnte?

Klingt davon etwas vertraut, hat das System bereits die Schwelle zur Unwartbarkeit überschritten, unabhängig von seinem Alter oder davon, wie es ursprünglich gebaut wurde.

Was Sie zuerst tun sollten

Viele Geschäftsführer haben an diesem Punkt den Impuls, einen kompletten Neubau vorzuschlagen. Das ist meist der falsche erste Schritt. Ein Neubau wirft Jahre angesammelter Geschäftslogik weg, einschließlich der Sonderfälle und Fehlerbehebungen, die nirgendwo außer im bestehenden Code dokumentiert sind, und er legt die Roadmap des Unternehmens für Monate auf Eis, während ein neues System erst wieder die Funktionalität des alten erreichen muss.

Ein besserer Ausgangspunkt ist eine ehrliche Bestandsaufnahme: Welche Teile des Systems sind wirklich gefährlich anzufassen, welche sind nur unangenehm, und welche sind eigentlich in Ordnung und brauchen noch keine Aufmerksamkeit? Die meisten unwartbaren Systeme haben einen kleinen Kern aus wirklich riskantem Code, umgeben von einem viel größeren Bereich, der einfach nur Tests und etwas Aufräumen braucht. Zuerst den gefährlichen Kern zu reparieren und sich dann nach außen vorzuarbeiten, stellt den größten Teil des Vertrauens wieder her, das ein Team braucht, ohne die Kosten oder das Risiko eines kompletten Neustarts. Legacy-Code zähmen beschreibt konkrete Techniken für diese Art der schrittweisen Wiederherstellung.

Der andere frühe Schritt ist einfach, das zu sichern, was Sie bereits haben. Klären Sie vor allem anderen, wer Zugriff auf das Repository, die Hosting-Accounts und die Domain hat, und stellen Sie sicher, dass dieser Zugriff nicht vollständig von einer Person abhängt, die im nächsten Quartal gehen könnte. Eine Codebasis, die schwer zu verstehen ist, ist ein ernstes Problem. Eine Codebasis, zu der niemand überhaupt Zugriff hat, ist noch schlimmer.

Wo Wolf-Tech ansetzt

Wolf-Tech arbeitet mit Unternehmen in genau dieser Situation: einem System, das das Geschäft noch am Laufen hält, das das aktuelle Team aber nicht mehr sicher ändern kann. Der erste Schritt ist meist ein Code-Audit, das die wirklich riskanten Teile eines Systems von den Teilen trennt, die nur unübersichtlich aussehen, damit die Korrektur das reale Problem trifft, statt Code neu zu schreiben, der nie wirklich kaputt war. Klingt das nach der Situation Ihres Teams, schreiben Sie an hello@wolf-tech.io oder sehen Sie sich an, wie die Leistungen Legacy-Code-Optimierung und Code-Quality-Beratung unter wolf-tech.io funktionieren.