Code übernehmen, den jemand anders geschrieben hat

Irgendwann passiert es vielen kleinen Firmen mit eigener Software: Der Freelancer, der die Anwendung gebaut hat, ist nicht mehr erreichbar, die Agentur hat sich aufgelöst, oder der Kollege, der „das mit der Website" gemacht hat, ist gegangen. Die Anwendung läuft weiter, aber niemand weiß genau, wie. Und dann kommt der erste Änderungswunsch oder der erste Fehler.

Dieser Beitrag beschreibt, wie Sie eine solche Übernahme geordnet angehen. Die Reihenfolge ist wichtig: erst sichern, dann verstehen, dann ändern.

Schritt 1: Eigentum und Zugänge klären

Bevor es um Technik geht, geht es um Kontrolle. Prüfen Sie, wem was gehört:

• Code-Repository: Liegt es in einem Konto Ihrer Firma oder im privaten Konto des früheren Entwicklers?
• Hosting und Server: Auf wessen Namen läuft der Vertrag, und wer hat Administratorzugang?
• Domain und DNS: Bei welchem Registrar, unter welchem Konto?
• Drittanbieter: Zahlungsanbieter, E-Mail-Versand, Kartendienste, KI-APIs. Auf welches Konto laufen die API-Schlüssel, und wer bezahlt sie?
• Rechte am Code: Was sagt der ursprüngliche Vertrag über Nutzungsrechte?

Liegt etwas davon im Konto einer Person, die nicht mehr für Sie arbeitet, hat die Überführung in ein Firmenkonto Vorrang vor allem anderen. Ein Repository auf GitHub lässt sich übertragen, eine Domain umziehen. Das geht aber nur, solange die Person kooperiert. Zögern Sie damit nicht.

Wenn der frühere Entwickler noch erreichbar ist

Nutzen Sie die Gelegenheit, solange sie besteht. Eine Stunde Gespräch kann Tage an Suche ersparen. Bieten Sie an, diese Zeit zu bezahlen, das erhöht meist die Bereitschaft. Sinnvolle Fragen:

• Wie startet man die Anwendung lokal, und was braucht man dafür?
• Wie wird eine neue Version ausgerollt?
• Gibt es Stellen, die man besser nicht anfasst, und warum?
• Welche Probleme sind bekannt, aber nie behoben worden?
• Laufen irgendwo geplante Jobs oder Skripte, die nicht im Repository liegen?
• Welche externen Dienste werden genutzt, und auf welches Konto laufen sie?

Lassen Sie die Antworten schriftlich festhalten oder nehmen Sie das Gespräch mit Einverständnis auf. Auch eine unvollständige Antwort ist besser als keine.

Schritt 2: Den aktuellen Stand sichern

Bevor jemand etwas verändert, brauchen Sie einen Stand, zu dem Sie zurückkehren können:

1. Den Code aus dem Repository klonen, oder, falls es keines gibt, die Dateien vom Server herunterladen und in ein neues Repository legen.
2. Prüfen, ob der Code im Repository wirklich dem entspricht, was auf dem Server läuft. Es kommt vor, dass direkt auf dem Server geändert wurde, ohne dass das je im Repository gelandet ist.
3. Eine Sicherung der Datenbank erstellen und testweise wiederherstellen. Eine Sicherung, die nie zurückgespielt wurde, ist eine Hoffnung, keine Sicherung.
4. Die Konfiguration des Servers dokumentieren: Umgebungsvariablen, geplante Jobs (cron), Webserver-Einstellungen.

Schritt 3: Die Anwendung lokal zum Laufen bringen

Der wichtigste technische Meilenstein ist, dass jemand anderes als der ursprüngliche Entwickler die Anwendung auf seinem Rechner oder in einer Testumgebung starten kann. Solange das nicht geht, ist jede Änderung ein Blindflug.

Dabei fallen meist Lücken auf: eine fehlende Umgebungsvariable, eine Abhängigkeit, die es so nicht mehr gibt, ein Datenbankschema, das nur auf dem Server existiert. Schreiben Sie jede dieser Lücken auf. Das Ergebnis ist eine Startanleitung, wie sie im README stehen sollte:

git clone git@github.com:ihre-firma/kundenportal.git
cd kundenportal
cp .env.example .env      # Werte aus dem Passwortmanager eintragen
npm ci
npm run db:migrate
npm run dev

Wenn Sie nach der Übernahme nur eine einzige Sache dokumentieren, dann diese.

Testen Sie die Anleitung, indem jemand sie auf einem frischen Rechner Schritt für Schritt befolgt, ohne nachzufragen. Jede Stelle, an der er hängen bleibt, ist eine Lücke in der Anleitung, nicht ein Fehler der Person. Erst wenn das ohne Hilfe gelingt, ist die Anleitung fertig.

Schritt 4: Eine Bestandsaufnahme machen

Jetzt geht es darum, das System zu verstehen, nicht zu bewerten. Eine Bestandsaufnahme beantwortet diese Fragen:

Frage	Wo man nachsieht
Welche Sprache, welches Framework, welche Versionen?	package.json, composer.json, requirements.txt, pyproject.toml
Sind die Versionen noch unterstützt?	End-of-Life-Übersichten der Projekte, etwa endoflife.date
Gibt es bekannte Sicherheitslücken in Abhängigkeiten?	npm audit, composer audit, pip-audit
Gibt es Tests, und laufen sie?	Ordner test, tests, __tests__; Testbefehl ausführen
Wie wird ausgerollt?	CI-Konfiguration, Skripte, Hoster-Einstellungen
Welche externen Dienste werden aufgerufen?	Umgebungsvariablen, Suche nach API-URLs im Code
Stehen Zugangsdaten im Code?	Suche nach password, secret, api_key, token

Der letzte Punkt verdient Aufmerksamkeit. Findet sich ein Zugangsschlüssel im Code oder in der Git-Historie, sollte er beim jeweiligen Anbieter erneuert werden. Ihn nur aus dem Code zu löschen reicht nicht, denn in der Historie bleibt er erhalten. Werkzeuge wie gitleaks durchsuchen die gesamte Historie danach.

Schritt 5: Klein anfangen

Die Versuchung ist groß, nach der Bestandsaufnahme vieles auf einmal zu modernisieren. Widerstehen Sie ihr. Die erste Änderung an fremdem Code sollte klein, gut prüfbar und für Ihr Geschäft nützlich sein, etwa ein bekannter Fehler oder eine überschaubare Erweiterung.

Der Grund: Mit der ersten Änderung testen Sie den gesamten Weg vom Code bis zur laufenden Anwendung. Branch anlegen, ändern, prüfen, ausrollen. Wenn dieser Weg einmal funktioniert hat, sind alle weiteren Änderungen weniger riskant. Scheitert er, merken Sie es an einer Kleinigkeit und nicht mitten in einem großen Umbau.

Vor jeder Änderung an Stellen ohne Tests lohnt sich ein sogenannter Charakterisierungstest: Er hält fest, was der Code heute tut, auch wenn das vielleicht nicht ganz richtig ist. Danach lässt sich ändern, ohne versehentlich anderes Verhalten mitzuverändern.

Was Sie vom alten Code nicht erwarten sollten

Fremder Code wirkt oft schlechter, als er ist. Jeder Entwickler hat eigene Vorlieben, und vieles, was auf den ersten Blick seltsam aussieht, hatte einen Grund, den man nicht mehr kennt. Ein Urteil wie „Das muss alles neu geschrieben werden" sollte Sie deshalb skeptisch machen, besonders wenn es nach wenigen Stunden Einblick fällt.

Eine Neuentwicklung ist manchmal richtig, etwa wenn das Framework seit Jahren keine Sicherheitsupdates mehr erhält und ein Upgrade aufwendiger wäre als ein Neubau. Sie sollte aber eine bewusste Entscheidung auf Grundlage der Bestandsaufnahme sein, nicht ein Reflex. Wie man die gefundenen Probleme priorisiert, beschreibt der Beitrag Technische Schulden in kleinen Firmen.

Übergabe-Checkliste für die Zukunft

Damit die nächste Übernahme leichter wird, sollte am Ende dieses Prozesses Folgendes vorliegen:

• Repository im Firmenkonto, Zugänge für alle Beteiligten personalisiert
• README mit Startanleitung, die jemand Neues tatsächlich ausprobiert hat
• .env.example mit allen benötigten Variablen, ohne echte Werte
• Zugangsdaten im Passwortmanager der Firma, nicht in Köpfen oder E-Mails
• Getestete Datenbanksicherung
• Kurze Beschreibung, wie ausgerollt wird
• Liste der externen Dienste mit Vertragsinhaber

Häufige Fragen

Was ist bei der Übernahme fremden Codes der erste Schritt?

Eigentum und Zugänge klären, noch vor jeder Technik. Prüfen Sie, auf wessen Konto Repository, Hosting, Domain und die API-Schlüssel der Drittanbieter laufen. Liegt etwas davon bei einer Person, die nicht mehr für Sie arbeitet, hat die Überführung in ein Firmenkonto Vorrang, solange diese Person noch kooperiert.

Muss übernommener Code neu geschrieben werden?

Nicht automatisch. Fremder Code wirkt oft schlechter, als er ist, und vieles, was seltsam aussieht, hatte einen Grund. Eine Neuentwicklung kann richtig sein, etwa wenn das Framework keine Sicherheitsupdates mehr erhält, sollte aber eine bewusste Entscheidung auf Grundlage einer Bestandsaufnahme sein.

Was tun, wenn im übernommenen Code Zugangsdaten stehen?

Den Schlüssel beim jeweiligen Anbieter erneuern. Ihn nur aus dem Code zu löschen reicht nicht, denn in der Git-Historie bleibt er erhalten. Werkzeuge wie gitleaks durchsuchen die gesamte Historie nach solchen Funden.

---

Die Bestandsaufnahme selbst ist meist eine eigene, gut abgrenzbare Aufgabe und eignet sich deshalb als erste Aufgabe, die bei uns kostenlos ist. Sie laden uns in Ihr Repository auf GitHub, GitLab, Bitbucket oder Azure DevOps ein, statt Zugangsdaten zu verschicken, und erhalten 48 Stunden nach Start einen schriftlichen Befund entlang der Fragen oben; gezählt wird von Montag 8 Uhr bis Freitag 16 Uhr. Bei einer großen Anwendung teilen wir die Bestandsaufnahme in mehrere Aufgaben auf. Aus den Funden werden Karten auf Ihrem Board: einzelne Fehler oder Erweiterungen, jede mit eigenen Abnahmekriterien, umgesetzt auf einem eigenen Branch und geliefert als Pull Request, den Sie prüfen. Im Prozess-Abo arbeiten wir diese Karten in Ihrer Reihenfolge ab, und jede Lieferung prüft und gibt ein Senior-Entwickler frei, bevor sie zu Ihnen geht. Mehr dazu unter Fehler beheben und Programmierung; typische Aufgaben mit Umfang und Abnahmekriterien stehen im Leistungskatalog.