Fremden Code verstehen und portieren

Warum niemand den Code mehr anfassen will

Die meiste Software, die in kleinen und mittleren Unternehmen im Einsatz ist, wurde nicht von großen Teams nach Lehrbuch entwickelt. Sie wurde von einem einzelnen Entwickler gebaut — vielleicht einem Freelancer, vielleicht einem Mitarbeiter, der inzwischen in Rente ist. Der Code funktioniert, aber er folgt keinem Standard, den ein beliebiger anderer Entwickler sofort versteht.

Das allein ist kein Drama. Es wird erst zum Problem, wenn etwas geändert werden muss und niemand mehr da ist, der den Code kennt. Dann steht ein Unternehmen vor einer Software, die wie eine Blackbox funktioniert: Daten gehen rein, Ergebnisse kommen raus, aber was dazwischen passiert, weiß keiner so genau.

Dazu kommt die Angst vor Seiteneffekten. Wer an einer Stelle etwas ändert, riskiert, dass an einer ganz anderen Stelle etwas kaputtgeht. Diese Angst ist berechtigt — vor allem wenn es keine Tests und keine Dokumentation gibt. Also fasst niemand den Code an. Solange es geht.

Irgendwann geht es nicht mehr. Das Betriebssystem, auf dem die Software läuft, bekommt keine Sicherheitsupdates mehr. Die Datenbank-Version wird vom Hersteller nicht mehr unterstützt. Die Programmiersprache ist so alt, dass kein aktueller Webserver sie mehr ausführt. Oder eine externe Anforderung — ein neuer Zahlungsdienstleister, E-Rechnung, eine ERP-Anbindung — erzwingt eine Änderung, die sich in der bestehenden Umgebung nicht mehr umsetzen lässt.

An diesem Punkt gibt es zwei Wege: Alles neu bauen oder den bestehenden Code verstehen und gezielt portieren. Der Neubau klingt verlockend, hat aber einen gewaltigen Nachteil: In der alten Software stecken Jahre an Geschäftslogik — Regeln, Sonderfälle, Berechnungen, die nirgends aufgeschrieben sind. Wer das System neu schreibt, muss all das erst wieder herausfinden. Das dauert länger und kostet mehr, als die meisten erwarten.

Systematisch lesen: Architektur und Datenfluss erkennen

Fremden Code zu lesen ist eine eigene Disziplin. Es hat wenig mit dem Schreiben von Code zu tun und viel mit Detektivarbeit. Man beginnt nicht bei Zeile eins und liest sich durch. Man beginnt bei den Fragen: Was tut diese Software? Welche Daten fließen wo hin? Wo liegt die Geschäftslogik?

Der erste Schritt ist immer ein Überblick über die Architektur. Wie ist die Software aufgebaut? Gibt es eine Datenbank, und wenn ja, welche Tabellen existieren? Welche externen Systeme werden angesprochen — Mailserver, Zahlungsdienstleister, Schnittstellen zu anderen Programmen? Welche Dateien gehören zum Kern der Anwendung und welche sind Hilfskonstruktionen?

Dann folgt der Datenfluss. Daten sind der rote Faden durch jede Software. Wenn Sie verstehen, welche Daten wo eingegeben werden, wie sie verarbeitet werden und wo sie am Ende landen, verstehen Sie das System. Nicht jede Zeile Code, aber die Struktur. Und die Struktur ist das, was zählt.

Konkret heißt das: Wir schauen uns die Datenbank-Struktur an, verfolgen die wichtigsten Prozesse durch den Code — etwa eine Bestellung von der Eingabe bis zur Rechnung — und dokumentieren, was wir finden. Dabei entdecken wir fast immer Dinge, die überraschen: Sonderfälle, die nur für einen bestimmten Kunden eingebaut wurden. Berechnungen, die von keiner Spezifikation abgedeckt sind. Workarounds für Probleme, die es vielleicht gar nicht mehr gibt.

Diese Analyse braucht Zeit. Je nach Umfang der Software sprechen wir von Tagen bis Wochen. Aber sie ist die Grundlage für alles, was danach kommt. Ohne dieses Verständnis ist jede Portierung ein Blindflug.

KI als Lesehilfe: Was funktioniert und was nicht

Seit es leistungsfähige KI-Sprachmodelle gibt, hat sich die Arbeit mit fremdem Code verändert. Nicht grundlegend, aber spürbar. KI kann Code lesen und in verständlicher Sprache erklären, was eine Funktion tut. Sie kann Muster erkennen, Abhängigkeiten aufzeigen und Vorschläge machen, wie ein Codeblock in einer anderen Programmiersprache aussehen könnte.

Das ist eine echte Hilfe — vor allem bei großen Codebasen, wo man allein Wochen bräuchte, um jede Funktion zu verstehen. Mit KI-Unterstützung geht die erste Analyse deutlich schneller. Wir nutzen das aktiv und es beschleunigt die Arbeit messbar.

Aber KI hat klare Grenzen. Sie versteht Code syntaktisch, nicht semantisch. Sie kann Ihnen sagen, dass eine Funktion einen Preis berechnet. Aber sie kann nicht beurteilen, ob die Berechnung korrekt ist, ob sie einem bestimmten Geschäftsvertrag entspricht oder ob der Sonderfall in Zeile 47 noch relevant ist. Das erfordert menschliches Urteil — jemanden, der Fragen stellt, Annahmen überprüft und Ergebnisse mit der Realität abgleicht.

Ein typisches Beispiel: KI übersetzt eine Funktion von PHP nach Python und das Ergebnis sieht syntaktisch korrekt aus. Aber die Rundungslogik weicht ab, weil die beiden Sprachen Dezimalzahlen unterschiedlich behandeln. Bei einer Preisberechnung kann das dazu führen, dass Rechnungsbeträge um Cent-Beträge abweichen. Das fällt keiner KI auf — aber einem erfahrenen Entwickler schon.

Deshalb ist unsere Regel: KI unterstützt, Menschen entscheiden. Wer sich blind auf KI-generierte Portierungen verlässt, handelt sich neue Probleme ein, die schwerer zu finden sind als die alten. Wenn Sie mehr darüber erfahren möchten, wie KI bei bestehenden Projekten sinnvoll eingesetzt wird, lesen Sie unseren Überblick zum Thema Vibe-Coding und KI-gestützte Entwicklung.

Portierung planen: Sprache, Framework, Architektur

Wenn die Analyse steht, beginnt die eigentliche Planung. Portierung heißt nicht einfach „den Code in einer anderen Sprache neu schreiben". Es heißt: Die Geschäftslogik, die im bestehenden Code steckt, in eine neue technische Umgebung überführen — so, dass sie genauso funktioniert wie vorher, aber auf einer Plattform, die Zukunft hat.

Dabei sind mehrere Entscheidungen zu treffen:

• Zielsprache und Framework: In welcher Programmiersprache und mit welchem Framework soll die Software künftig laufen? Die Entscheidung hängt davon ab, was die Software tut, wie sie betrieben wird und wer sie künftig warten soll.
• Umfang der Portierung: Muss alles portiert werden oder nur der Kern? Oft gibt es Funktionen, die seit Jahren niemand nutzt. Die kann man weglassen. Das spart Zeit und Geld.
• Datenbank-Migration: Kann die bestehende Datenbank weiterverwendet werden oder muss sie umstrukturiert werden? Wie werden die vorhandenen Daten übernommen?
• Schnittstellen: Welche externen Systeme müssen angebunden werden? Gibt es neue Anforderungen — etwa E-Rechnung oder eine ERP-Anbindung —, die gleich miterledigt werden können?
• Betriebsumgebung: Wo soll die Software künftig laufen? Auf einem eigenen Server, in der Cloud, in einem Container? Für Fälle, in denen die Software nicht sofort portiert werden kann, ist auch eine Containerisierung eine Option, die Zeit verschafft.

Die wichtigste Frage ist aber eine andere: Was muss nach der Portierung genauso funktionieren wie vorher? Das klingt selbstverständlich, ist aber in der Praxis der schwierigste Teil. Denn „genauso wie vorher" setzt voraus, dass man genau weiß, was „vorher" war. Und genau hier zahlt sich die gründliche Analyse aus dem vorherigen Schritt aus.

Checkliste: Was vor der Portierung geklärt sein muss

Bevor eine Zeile neuer Code geschrieben wird, sollten folgende Punkte beantwortet sein:

1. Ist die bestehende Software vollständig verfügbar? Quellcode, Datenbank, Konfigurationsdateien, Zugangsdaten — alles muss vorliegen. Fehlende Teile sind ein Risiko.
2. Gibt es eine lauffähige Testumgebung? Wir brauchen die Möglichkeit, die alte Software parallel zur neuen zu betreiben, um Ergebnisse vergleichen zu können.
3. Welche Geschäftsprozesse sind kritisch? Nicht alles ist gleich wichtig. Rechnungsstellung, Datenexporte, Kundenverwaltung — was muss vom ersten Tag an funktionieren?
4. Wer kennt die fachlichen Regeln? Auch wenn der Entwickler weg ist — gibt es im Unternehmen Menschen, die wissen, wie die Software fachlich funktionieren soll? Buchhalter, Sachbearbeiter, langjährige Mitarbeiter — ihr Wissen ist Gold wert.
5. Was sind die neuen Anforderungen? Wenn schon portiert wird, sollte klar sein, welche zusätzlichen Anforderungen direkt mit umgesetzt werden sollen. Das vermeidet doppelte Arbeit.
6. Gibt es einen realistischen Zeitrahmen? Portierung ist kein Wochenendprojekt. Je nach Umfang dauert sie Wochen bis Monate. Wer unter Zeitdruck steht, sollte das von Anfang an kommunizieren — dann kann man Prioritäten setzen.

Nicht jede dieser Fragen lässt sich sofort beantworten. Aber jede unbeantwortete Frage ist ein Risiko, das später Zeit und Geld kostet. Deshalb klären wir so viel wie möglich vor dem Start.

Qualitätssicherung beim Portieren

Portierung ohne Qualitätssicherung ist wie ein Umzug ohne zu prüfen, ob alle Kartons angekommen sind. Man merkt erst Wochen später, dass etwas fehlt — und dann ist die Suche aufwändig.

Das Kernprinzip ist einfach: Die neue Software muss bei gleichen Eingaben die gleichen Ergebnisse liefern wie die alte. Das klingt trivial, ist aber in der Praxis die größte Herausforderung. Denn „gleiche Ergebnisse" bedeutet: identisch bis auf die letzte Nachkommastelle, in jeder Sonderkonstellation, auch bei Fehlerfällen.

Wir arbeiten deshalb mit parallelem Betrieb. Die alte und die neue Software laufen eine Zeit lang gleichzeitig. Echte Geschäftsvorfälle werden in beiden Systemen verarbeitet und die Ergebnisse verglichen. Abweichungen werden analysiert und behoben, bevor die alte Software abgeschaltet wird.

Zusätzlich schreiben wir automatisierte Tests für die kritischen Geschäftsprozesse. Diese Tests sind kein Luxus — sie sind eine Versicherung. Wenn in sechs Monaten jemand etwas an der Software ändern muss, zeigen die Tests sofort, ob die Änderung etwas kaputt gemacht hat. Das ist ein Vorteil, den die alte Software nie hatte.

Ehrlich gesagt: Hundertprozentige Sicherheit gibt es nicht. Bei jeder Portierung gibt es ein Restrisiko, dass ein obskurer Sonderfall übersehen wird. Aber mit systematischer Analyse, parallelem Betrieb und automatisierten Tests lässt sich dieses Risiko auf ein Minimum reduzieren. Und es ist in jedem Fall geringer als das Risiko, eine veraltete Software auf einem unsicheren System ohne jede Änderungsmöglichkeit weiterlaufen zu lassen.

Wenn Sie sich einen umfassenden Überblick über den gesamten Bereich der Legacy-Software-Modernisierung verschaffen möchten, finden Sie dort die verschiedenen Ansätze im Zusammenhang erklärt.