Zombie-Code

Ein Programm besteht aus vielen Anweisungen, die ein Entwickler geschrieben hat. Über die Jahre kommen neue Funktionen dazu, alte werden ersetzt. Die alten Anweisungen werden dabei oft nicht gelöscht, sondern nur stillgelegt oder vergessen. Genau solche Reste nennt man Zombie-Code: Er ist eigentlich tot, liegt aber weiter im Projekt herum. Manchmal wird er sogar noch ausgeführt, ohne dass irgendjemand davon weiß. Der Name spielt genau darauf an: etwas, das nicht mehr leben sollte, sich aber trotzdem noch bewegt.

Was die alten Reste wirklich kosten

Auf den ersten Blick klingt Zombie-Code harmlos. Ungenutzte Zeilen tun schließlich nichts. Das Problem ist nicht die Rechenleistung, sondern die Aufmerksamkeit der Menschen. Wer ein Programm ändern will, muss erst verstehen, was darin passiert. Jede tote Zeile kostet dabei Lesezeit und erzeugt Zweifel.

Besonders teuer wird es bei Fehlern. Ein Entwickler sucht stundenlang in einem Programmteil nach der Ursache eines Problems. Am Ende stellt sich heraus, dass dieser Teil seit drei Jahren gar nicht mehr aufgerufen wird. Solche Sackgassen häufen sich in großen Projekten. In Firmen mit Millionen Zeilen Code ist das ein realer Kostenfaktor.

Dazu kommt ein Sicherheitsaspekt. Alter Code enthält oft veraltete Verfahren, etwa zum Speichern von Passwörtern. Wird er nie gepflegt, aber unter bestimmten Umständen doch ausgeführt, entsteht eine Lücke. Angreifer suchen gezielt nach solchen vergessenen Ecken. Ein Zombie ist also nicht nur lästig, sondern manchmal gefährlich.

Wie Code zum Zombie wird

Der häufigste Weg ist der bequeme. Ein Entwickler ersetzt eine Funktion, löscht die alte aber nicht. Stattdessen schaltet er sie mit einem Kommentar oder einem Schalter ab. Das fühlt sich sicher an, falls die neue Lösung Probleme macht. Nur nimmt sich später niemand die Zeit, den Rest zu entfernen.

Ein zweiter Weg führt über sogenannte Feature Flags. Das sind Schalter im Programm, mit denen Firmen Funktionen für einzelne Nutzergruppen an- oder abschalten. Wird ein Schalter nach dem Test nie wieder angefasst, bleibt der zugehörige Code für immer im dunklen Zustand liegen. Er ist da, er könnte laufen, aber niemand beobachtet ihn.

Wichtig ist die Abgrenzung zu unerreichbarem Code. Unerreichbarer Code kann technisch nie ausgeführt werden, etwa weil er hinter einer Bedingung steht, die immer falsch ist. Solche Stellen findet ein Analyseprogramm meist automatisch. Zombie-Code ist tückischer: Er ist technisch erreichbar, wird aber praktisch nicht mehr gebraucht. Das erkennt keine Software zuverlässig, sondern nur ein Mensch, der das Produkt kennt.

Zombies in großen Softwareprojekten und in KI-Systemen

Jede große Software schleppt solche Altlasten mit. Banken betreiben Programme, die seit den 1980er Jahren gewachsen sind. Betriebssysteme enthalten Routinen für Geräte, die es längst nicht mehr gibt. Wenn in den Nachrichten von technischen Schulden die Rede ist, gehört Zombie-Code fast immer dazu. Gemeint ist damit die Summe der Abkürzungen, die man später mit Zinsen zurückzahlt.

Mit KI-Werkzeugen bekommt das Thema neue Bedeutung. Programme wie GitHub Copilot schlagen automatisch ganze Codeabschnitte vor. Entwickler übernehmen diese Vorschläge oft schneller, als sie sie prüfen. Dadurch entstehen mehr Zeilen in kürzerer Zeit, und ein Teil davon wird nie wirklich benutzt. Mehrere Studien aus der Branche berichten seit 2024 von wachsendem Anteil an dupliziertem und ungenutztem Code.

Gegenmittel gibt es. Firmen messen, welche Programmteile im laufenden Betrieb tatsächlich aufgerufen werden. Was monatelang keine einzige Anfrage sieht, kommt auf die Löschliste. Ein verbreiteter Irrtum ist übrigens, dass Löschen riskant sei. Da jede ernsthafte Firma alle alten Versionen in einer Versionsverwaltung speichert, lässt sich gelöschter Code jederzeit zurückholen. Aufheben im laufenden Projekt ist deshalb fast nie nötig.