Fremden Code übernehmen: eine Checkliste vor dem ersten Deploy

Die Entwickler sind weg, die Dokumentation ist dünn, und irgendwo läuft das System weiter und bedient echte Kunden. Diese Ausgangslage sehen wir häufig. Der Reflex ist, sofort aufzuräumen. Das ist fast immer der falsche erste Schritt.

Bevor wir eine übernommene Anwendung produktiv verändern, arbeiten wir die folgende Liste ab. Sie kostet ein bis zwei Tage und spart regelmäßig Wochen.

1. Können wir es überhaupt bauen?

Klingt banal, ist es nicht. Wir prüfen, ob sich das Projekt auf einem frischen Rechner aus dem Repository heraus starten lässt — ohne Zugriff auf den Laptop einer Person, die nicht mehr da ist.

Wenn das nicht gelingt, ist das der erste Auftrag. Eine Codebasis, die nur auf einem bestimmten Rechner baut, ist faktisch nicht wartbar.

2. Was läuft tatsächlich in Produktion?

Der Stand im main-Branch ist nicht zwingend der Stand, der live ist. Wir vergleichen den deployten Artefaktstand mit dem Repository. Abweichungen sind häufiger, als man denkt, und sie erklären oft genau die Fehler, die niemand reproduzieren konnte.

3. Wo liegen die Daten, und gibt es ein Backup?

Wir klären drei Dinge:

• Wo liegt die Datenbank, und wer hat Zugriff?
• Wann wurde zuletzt ein Backup eingespielt — nicht nur erstellt?
• Welche personenbezogenen Daten werden verarbeitet, und auf welcher Grundlage?

Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung, kein Backup.

4. Welche Abhängigkeiten sind abgekündigt?

Ein schneller Blick auf veraltete Pakete und offene Sicherheitshinweise zeigt, wie dringend die Lage ist. Wichtig ist die Unterscheidung: Ein veraltetes Paket ist ein Wartungsthema. Ein Paket mit bekannter Sicherheitslücke im Authentifizierungspfad ist ein Notfall.

5. Gibt es irgendeinen Test?

Oft lautet die Antwort nein. Das ist kein Grund zur Panik, aber es bestimmt das Vorgehen: Ohne Netz ändert man nichts Großes. Wir schreiben dann zuerst ein paar grobe Tests um die kritischen Abläufe — Anmeldung, Bezahlung, Datenexport — bevor wir irgendetwas umbauen.

Und erst danach: aufräumen

Refactoring ist nicht der erste Schritt, sondern der vierte oder fünfte. Zuerst Verstehen, dann Absichern, dann Stabilisieren — und erst dann Verbessern.

Wer in umgekehrter Reihenfolge arbeitet, baut sauberen Code auf einem Fundament, das er nicht kennt. Das fällt irgendwann auf die Füße, meist freitagnachmittags.