Veralteter Code: Die Warnung, die Sie weiterhin ignorieren, wird letztendlich alles zerstören.

Jedes Softwareprojekt stößt irgendwann auf veralteten Code, Komponenten, die als überholt gekennzeichnet, nicht mehr empfohlen oder zur Entfernung vorgesehen sind. @deprecated Annotation in Java, die DeprecationWarning In Python sind beispielsweise die Durchstreichungen in der Autovervollständigung Ihrer IDE Signale aus dem Quellcode, die darauf hinweisen, dass etwas, das Sie verwenden oder pflegen, überholt ist. Werden diese Signale ignoriert, häuft sich das Risiko unbemerkt an, bis eine Abhängigkeit entfernt wird, ein Sicherheitspatch eine veraltete API überspringt oder ein Framework-Upgrade alles unbrauchbar macht, was noch auf etwas basiert, das vor drei Hauptversionen als veraltet markiert wurde.

Zu verstehen, was „veraltet“ bedeutet, warum es wichtig ist und wie man systematisch damit umgeht, gehört zu den wichtigsten Wartungskompetenzen eines Entwicklerteams. Dieser Leitfaden bietet einen umfassenden Überblick: klare Definitionen, Vergleiche mit ähnlichen Begriffen, Warnungen zu veralteten Funktionen in verschiedenen Programmiersprachen und ein strukturierter Ansatz für die Verwaltung veralteter Abhängigkeiten, bevor diese zu Produktionsproblemen führen.

Was ist veralteter Code?

Als veralteter Code gelten Funktionen, Methoden, APIs, Bibliotheken oder ganze Komponenten, die zwar noch funktionieren, deren Verwendung aber offiziell nicht mehr empfohlen wird. Der Code lässt sich weiterhin kompilieren, ausführen und liefert Ergebnisse, doch die Entwickler haben angekündigt, ihn in einer zukünftigen Version zu entfernen, durch eine bessere Alternative zu ersetzen oder ihn einfach nicht mehr zu pflegen oder zu aktualisieren. Die Verwendung veralteten Codes bedeutet, sich auf etwas zu verlassen, um das sich die Verantwortlichen nicht mehr kümmern.

Die Kennzeichnung als veraltet ist ein Kommunikationsmechanismus, kein technischer Zustand. Wenn ein Bibliotheksentwickler eine Funktion als veraltet markiert, bedeutet das: „Diese Funktion funktioniert zwar noch, aber wir beabsichtigen, sie zu entfernen. Sie sollten daher vorher auf eine andere Funktion umsteigen.“ Die Zeitspanne zwischen der Kennzeichnung und der tatsächlichen Entfernung variiert – sie kann eine Hauptversion oder fünf Jahre betragen –, aber die Richtung ist immer dieselbe: Veraltet bedeutet, dass die Funktion irgendwann entfernt wird.

Deprecated vs. Depreciated: Die Rechtschreibverwirrung

Diese beiden Wörter werden häufig verwechselt, und Rechtschreibprüfungen helfen dabei nicht, da es sich in beiden Fällen um echte englische Wörter mit unterschiedlichen Bedeutungen handelt.

Veraltete (In der Softwarebranche): Als veraltet gekennzeichnet, nicht mehr empfohlen, zur Entfernung vorgesehen. Die korrekte Bezeichnung für Softwarekontexte.

Abgeschrieben (im Rechnungswesen): Im Laufe der Zeit an Wert verlierend. Zum Beispiel: „Die Serverhardware wurde über drei Jahre abgeschrieben.“

Wenn in einem technischen Dokument „veralteter Code“ steht, ist damit fast immer tatsächlich veralteter Code gemeint. Der Autor hat den Buchhaltungsbegriff verwendet, meinte aber den Softwarebegriff. Dieser Fehler ist so häufig, dass er sogar in den Search Console-Daten zu diesem Artikel auftaucht. Verwenden Sie daher in der Softwareentwicklung immer den entsprechenden Begriff „veralteter Code“. veraltet.

Veraltet vs. überholt vs. Legacy vs. toter Code

Diese Begriffe sind zwar verwandt, beschreiben aber unterschiedliche Zustände des Codes. Ihre Vermischung führt zu ungenauen Gesprächen und falschen Priorisierungsentscheidungen.

Bedingungen	Was es bedeutet	Wurde es entfernt?	Wird es gepflegt?	Risikostufe
Veraltete	Offiziell nicht empfohlen, zur zukünftigen Entfernung vorgemerkt.	Nein, noch vorhanden	Nein, die Wartungsarbeiten wurden eingestellt.	Mittelgroß, wächst mit der Zeit
Überholt	Nicht mehr relevant oder anwendbar; ersetzt	Manchmal	Nein	Medium-High
Legacy	Alter Code, der noch funktioniert und möglicherweise noch im Produktiveinsatz ist	Nein, noch aktiv	Selten	Variabel, hängt von der Änderungsrate ab
Toter Code	Während der Hinrichtung weder angerufen noch erreicht.	Nein, noch im Quellcode	Nicht verfügbar, läuft nie	Niedriges bis mittleres Migrations-/Auditrisiko
Veralteter Code	Code, der seit langer Zeit nicht mehr verändert wurde, aber nicht formell als veraltet gilt	Nein	Unklar	Medium, kann Annahmen verbergen

Veraltet vs. obsolet„Veraltet“ ist eine formale Kennzeichnung; jemand hat es explizit mit „Veraltet“ markiert. @deprecated oder eine entsprechende Mitteilung herausgegeben hat. „Veraltet“ ist eine weniger präzise Beschreibung; der Code funktioniert möglicherweise noch, hat aber angesichts moderner Alternativen keinen sinnvollen Anwendungsfall mehr. Jeder als veraltet gekennzeichnete Code ist letztendlich überholt, aber nicht jeder überholte Code wurde formell als veraltet markiert.

Veraltet vs. entferntVeralteter Code ist weiterhin im Quellcode vorhanden. Entfernter Code ist gelöscht. Die Übergangsfrist ist der Zeitraum zwischen diesen beiden Zuständen – die Zeit, die Sie für die Migration haben, bevor Ihr Code nicht mehr funktioniert.

Veraltet vs. LegacyLegacy-Code ist alter Produktionscode, der oft noch aktiv genutzt und gepflegt wird und aus einer früheren Technologieära stammt. Veralteter Code ist explizit zur Entfernung gekennzeichnet. Legacy-COBOL-Programme, die tägliche Transaktionen verarbeiten, sind nicht veraltet; sie sind zwar Legacy-Code, werden aber aktiv gepflegt. Eine vom Bibliotheksanbieter als veraltet gekennzeichnete COBOL-API-Funktion ist veraltet.

Außer Betrieb nehmen vs. stilllegenDie Kennzeichnung als veraltet ist ein technisches Signal innerhalb einer Codebasis oder Bibliothek. Die Stilllegung hingegen ist eine operative Entscheidung, bei der ein Dienst abgeschaltet, die Infrastruktur entfernt und der Support für ein Produkt beendet wird. Eine veraltete API kann unter Umständen noch jahrelang funktionieren; eine stillgelegte API wird zu einem bestimmten Datum abgeschaltet.

So sieht „Veraltet“ aus: Warnungen in verschiedenen Sprachen

Warnungen vor veralteten Funktionen können je nach Programmiersprache und verwendeten Werkzeugen unterschiedlich aussehen. Sie sofort zu erkennen, ist der erste Schritt, um darauf zu reagieren.

Python: DeprecationWarning

python

import warnings

# Marking a function as deprecated
def old_function():
    warnings.warn(
        "old_function is deprecated, use new_function instead",
        DeprecationWarning,
        stacklevel=2
    )
    # original implementation

def new_function():
    # improved implementation
    pass

Python gibt zur Laufzeit Warnungen zu veralteten Funktionen aus. Die übliche Compilermeldung lautet:

DeprecationWarning: old_function is deprecated, use new_function instead

Oder für Drittanbieterpakete:

DeprecationWarning: pkg_resources is deprecated as an API.
Use importlib.resources or importlib.metadata instead.

Java: @Deprecated-Annotation

Java

public class LegacyProcessor {

    @Deprecated
    public void processData(String input) {
        // old implementation
    }

    // Replacement method
    public void processDataV2(String input, ProcessOptions options) {
        // new implementation
    }
}

Der Java-Compiler erzeugt:

Note: SomeFile.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

JavaScript/TypeScript: JSDoc @deprecated

Javascript

/**
 * @deprecated Use fetchUserById() instead.
 * This function will be removed in version 4.0.
 */
function getUser(id) {
    // old implementation
}

// Modern replacement
async function fetchUserById(id) {
    // new implementation
}

Typoskript

class ApiClient {
    /** @deprecated Use post() with typed options instead */
    sendRequest(url: string): Promise<any> {
        // deprecated implementation
    }
}

IDEs-Anzeige getUser mit einem Durchstreichen an jeder Stelle, an der es aufgerufen wird, und TypeScripts @typescript-eslint/no-deprecated Die Regel kennzeichnet es in CI.

C++: [[veraltet]] Attribut

cpp

// C++14 and later
[[deprecated("Use processV2() instead")]]
void process(int value) {
    // old implementation
}

void processV2(int value, ProcessFlags flags = ProcessFlags::Default) {
    // new implementation
}

Compiler erzeugen:

warning: 'process' is deprecated: Use processV2() instead [-Wdeprecated-declarations]

Swift: @available mit veraltet

schnell

@available(*, deprecated, renamed: "fetchUser(withID:)")
func getUser(id: String) -> User {
    // old implementation
}

func fetchUser(withID id: String) -> User {
    // replacement
}

Kotlin/Java: @Deprecated mit ReplaceWith

Kotlin

@Deprecated(
    message = "Use processItems() instead",
    replaceWith = ReplaceWith("processItems(items)"),
    level = DeprecationLevel.WARNING
)
fun handleItems(items: List<Item>) {
    // deprecated
}

fun processItems(items: List<Item>) {
    // replacement
}

Warum veralteter Code echte Probleme verursacht

Veralteter Code ist nicht nur ein Problem der Systempflege. Er birgt konkrete, sich gegenseitig verstärkende Risiken in vier Dimensionen:

Sicherheitslücken. Veraltete APIs und Bibliotheken erhalten keine Sicherheitsupdates mehr. Eine veraltete Bibliothek mit einer ungepatchten CVE stellt eine permanente Sicherheitslücke dar; die Entwickler beheben diese nicht mehr, da sie einen Wechsel zu einer anderen Bibliothek anstreben. Organisationen, die veraltete Komponenten verwenden, setzen bewusst auf bekanntermaßen anfälligen Code.

Abhängigkeitsbruch bei Aktualisierungen. Der Hinweis auf die veraltete Funktion existiert genau deshalb, weil die Entfernung bevorsteht. Wenn das Hauptversions-Upgrade erscheint und die veraltete API entfernt, werden alle Systeme, die noch darauf angewiesen sind, gleichzeitig und zum denkbar ungünstigsten Zeitpunkt – während eines eigentlich routinemäßigen Upgrades – nicht mehr funktionieren.

Erhöhter Wartungsaufwand. Veralteter Code erfordert von Entwicklern, zwei mentale Modelle gleichzeitig zu beherrschen: die Funktion des alten Codes und die Funktion des neuen Äquivalents. Jedes neue Teammitglied muss lernen, welche Teile der Codebasis vermieden werden sollten und warum. Diese doppelte Komplexität verstärkt sich mit jeder weiteren veralteten Komponente.

Technische Schulden häufen sich. Jede veraltete Abhängigkeit stellt eine Einheit technischer Schulden dar. Im Gegensatz zu anderen Schulden hat veralteter Code eine Frist: Er wandelt sich von „Warnung“ zu „fehlerhaft“, sobald die veraltete Komponente tatsächlich entfernt wird.

Wie man mit veralteten Abhängigkeiten in einem Softwareprojekt umgeht

Schritt 1: Alle Abschreibungen erfassen

Führen Sie einen systematischen Scan durch, anstatt veraltete Komponenten einzeln zu ermitteln. Die meisten Tools bieten Möglichkeiten, das gesamte Inventar anzuzeigen:

bash

# Python: find all DeprecationWarning instances
python -W error::DeprecationWarning -m pytest

# JavaScript/Node.js: run with deprecation tracing
node --trace-deprecation app.js

# Java: compile with full deprecation details
javac -Xlint:deprecation *.java

# npm: find deprecated packages
npm outdated
npm audit

Schritt 2: Klassifizierung nach Risiko

Nicht alle veralteten Funktionen erfordern sofortiges Handeln. Klassifizieren Sie jede einzelne:

Priorität	Eigenschaften	Action
Kritische	Veraltete, sicherheitskritische Bibliothek; bekannte Sicherheitslücke (CVE); wird in der nächsten Hauptversion entfernt.	Sofort umziehen
Hoch	In der aktuellen Hauptversion als veraltet markiert; aktive Warnungen in der CI-Pipeline.	Zeitplan für den aktuellen oder nächsten Sprint
Medium	Veraltet, wird aber noch für mindestens zwei Hauptversionen unterstützt; kein Sicherheitsrisiko	Zum Backlog mit Zeitleiste hinzufügen
Niedrig	Veraltete Annotation im internen Code mit geringer Änderungsrate	Verfolgen und adressieren Sie dies während des zugehörigen Refactorings.

Schritt 3: Alle Verwendungen vor der Migration ermitteln

Bevor Sie eine veraltete Komponente ändern, ermitteln Sie alle Stellen, an denen sie verwendet wird. Eine Änderung ohne vollständige Übersicht birgt das Risiko, dass Verwendungen übersehen werden, die unbemerkt zu Fehlern führen.

python

# Using grep for basic search
grep -r "old_function" src/

# Using ast-grep for code-aware search (TypeScript/JS)
ast-grep --pattern 'getUser($ID)' --lang ts

# Using ripgrep with file type filtering
rg "deprecated_method" --type java

Bei großen Codebasen erzeugen automatisierte statische Analysetools eine vollständige Querverweistabelle genauer als die manuelle Suche mit grep, insbesondere bei indirekten Verwendungen durch dynamische Dispatch oder Vererbung.

Schritt 4: Systematisch migrieren

Ersetzen Sie veraltete Verwendungen nacheinander und überprüfen Sie jede einzelne, bevor Sie zur nächsten übergehen:

python

# Before: deprecated
import imp
module = imp.load_source('mymodule', '/path/to/mymodule.py')

# After: replacement
import importlib.util
spec = importlib.util.spec_from_file_location('mymodule', '/path/to/mymodule.py')
module = importlib.util.module_from_spec(spec)
spec.loader.exec_module(module)

Javascript

// Before: deprecated event property
document.addEventListener('keydown', (event) => {
    const key = event.keyCode;  // deprecated
});

// After: modern replacement
document.addEventListener('keydown', (event) => {
    const key = event.key;   // current standard
});

Schritt 5: Hinzufügen von Deprecation Gates zu CI/CD

Verhindern, dass nach der Bereinigung neue veraltete Verwendungen in die Codebasis gelangen:

YAML

# .github/workflows/deprecation-check.yml
- name: Check for deprecated API usage (Java)
  run: javac -Xlint:deprecation -Werror src/**/*.java

- name: Check for deprecated packages (Node)
  run: npm audit --audit-level=moderate

- name: ESLint no-deprecated rule (TypeScript)
  run: npx eslint --rule '{"@typescript-eslint/no-deprecated": "error"}' src/

Festlegung einer Abschaffungsrichtlinie

Organisationen, die den Umgang mit veralteten Produkten gut handhaben, behandeln dies als eine strategische und nicht nur als eine technische Frage. Eine Richtlinie zur Abschaffung veralteter Produkte definiert:

Wer kann das abwerten? Ein einzelner Entwickler sollte eine weit verbreitete interne API nicht ohne Rücksprache mit dem Team eigenmächtig als veraltet kennzeichnen. Entscheidungen über die Kennzeichnung als veraltet sollten unter Einbeziehung der Verantwortlichen der verwendeten Komponenten getroffen werden.

Wie lange die Abschreibungsperiode dauert. Ein sinnvoller Standardwert: eine Ankündigungsfrist von einem Hauptversionszyklus vor der Entfernung. Bei öffentlichen APIs zwei Hauptversionszyklen. Bei internen APIs ein Releasezyklus.

Wie die Abschaffung von Funktionen kommuniziert wird. Anmerkungen im Code, Einträge im Änderungsprotokoll und direkte Benachrichtigungen an bekannte Nutzer werden berücksichtigt. Ein Hinweis auf eine veraltete Funktion, der nur in einem Codekommentar enthalten ist, wird übersehen.

Was genau bedeutet „entfernt“? Wurde der Code gelöscht? In ein separates optionales Paket verschoben? Hinter einem Feature-Flag versteckt? Definieren Sie den Endzustand klar.

Wie der Migrationspfad dokumentiert ist. Jede Veraltungsanmerkung sollte einen Verweis auf den Ersatz enthalten. @deprecated Use fetchUserById() instead ist nützlicher als @deprecated.

Funktioniert veralteter Code noch?

Ja, solange, bis es eben nicht mehr funktioniert. Veralteter Code läuft normal, bis er in einer bestimmten Version tatsächlich entfernt wird. Genau das ist die gefährlichste Eigenschaft veralteten Codes: Er erzeugt ein trügerisches Sicherheitsgefühl. Systeme, die jahrelang mit veralteten APIs betrieben wurden, mögen stabil erscheinen, doch das Risiko eines plötzlichen Ausfalls steigt mit jedem Release-Zyklus.

Die Antwort auf die Frage „Ist es sicher, veralteten Code auszuführen?“ lautet: Es kommt darauf an, wie nah das Datum der Abschaffung ist und wie der Sicherheitsstatus der veralteten Komponente ist. Eine Funktion, die in einer Nebenversion einer aktiv gepflegten Bibliothek ohne bekannte CVEs als veraltet markiert wurde, birgt ein geringes unmittelbares Risiko. Eine veraltete Authentifizierungsbibliothek mit einer ungepatchten Sicherheitslücke und einem angekündigten Enddatum birgt hingegen ein hohes unmittelbares Risiko.

Wie SMART TS XL Identifiziert veralteten Code in unternehmensweiten Systemen

In einem Projekt mit nur einer Programmiersprache lässt sich veralteter Code durch Ausführen des richtigen Compiler-Flags oder der richtigen Lint-Regel finden. In einer Unternehmensumgebung, die COBOL, JCL, Java, Python und moderne Dienste umfasst, müssen die veralteten Komponenten jeder Sprache gleichzeitig gefunden werden, und die Beziehungen zwischen ihnen sind genauso wichtig wie die Veraltungen selbst.

SMART TS XL statische Code-Analyse durchsucht alle Sprachen der Umgebung und deckt gleichzeitig veraltete Annotationen, überholte API-Nutzungen und tote Codemuster im gesamten Quellcode auf. Wenn ein COBOL-Copybook als veraltet markiert wird, SMART TS XL Es identifiziert jedes Programm, das es einbindet. Wenn eine Java-API-Methode als veraltet markiert wird, verfolgt es jeden Aufrufpunkt in allen Diensten des Portfolios.

Das Wirkungsanalyse Diese Funktion geht noch einen Schritt weiter: Bevor eine veraltete Komponente entfernt wird, ermittelt sie den gesamten Umfang der Auswirkungen – welche Programme, Job-Streams und nachgelagerten Dienste betroffen sein werden – und zwar in jeder Programmiersprache. So wird die riskante Frage „Was wird kaputtgehen?“ in eine strukturierte, detaillierte Liste aller Punkte umgewandelt, die vor der Entfernung validiert werden müssen.

Das Unternehmenssuche Diese Funktion ermöglicht die Abfrage des Inventars: Jede Verwendung einer bestimmten veralteten Funktion, jeder Verweis auf ein veraltetes Copybook, jeder Aufruf einer veralteten API – alles in Sekundenschnelle und über Millionen von Codezeilen in verschiedenen Sprachen hinweg. Modernisierung des Altbestands Bei Programmen, bei denen das Inventar veralteter Komponenten den Ausgangspunkt für die Bestimmung des Migrationsumfangs bildet, ersetzt diese Suchfunktion wochenlange manuelle Prüfungen durch eine gezielte Abfrage.