Fremden Code übernehmen und verstehen: So gehen Sie mit Altcode um

Autor: Thomas Schmid, Geschäftsführer von Canetron

“Der Entwickler hat gekündigt und niemand versteht seinen Code." Dieser Satz löst in vielen Unternehmen kalten Schweiß aus – zu Recht. Ein kritisches System mit Altcode, von dem der Geschäftsbetrieb abhängt, ist eine Blackbox. Und die Person, die den Schlüssel hatte, ist längst nicht mehr erreichbar.

Diese Situation ist im Mittelstand keine Seltenheit. Die entscheidenden Fragen lauten: Wie kann man den bestehenden Code verstehen und bewerten? Und welcher Weg ist danach der richtige – Weiterentwicklung, Portierung oder komplette Neuentwicklung der Software?

In diesem Beitrag zeige ich Ihnen den methodischen Ansatz, mit dem fremder Code systematisch erfasst und verstanden werden kann – als Grundlage für eine fundierte Entscheidung über die weitere Strategie.

---

Die Herausforderung:
Fremden Softwarecode verstehen

Ein häufiger Fehler bei der Übernahme bestehender Softwareprojekte: Entwickler stürzen sich sofort auf den Code und versuchen, ihn zu verstehen – oft mit frustrierenden Ergebnissen, unnötigem Zeitaufwand und falschen Schlussfolgerungen.

Typische Schwierigkeiten
bei der Übernahme von Altcode

• Fehlende Dokumentation: Die meisten Projekte sind unzureichend dokumentiert
• Verlorenes Kontextwissen: Warum wurden damals bestimmte Entscheidungen getroffen?
• Implizite Anforderungen: Viele Anforderungen wurden nie schriftlich festgehalten
• Individuelle Programmierstile: Jeder Entwickler hat seine eigene Handschrift

Diese Herausforderungen führen dazu, dass die Einarbeitung in fremden Software-Code oft wochen- oder monatelang dauert – und dennoch besteht das Risiko, dass wichtige Zusammenhänge übersehen werden.

---

Die methodische Lösung:
Der Kontext vor dem Altcode

Bei Canetron setzen wir auf einen anderen Ansatz: Wir analysieren zuerst den Kontext und die Geschäftsprozesse, bevor wir uns dem Code zuwenden. Diese Methodik führt zu einem tieferen Verständnis und besseren Ergebnissen.

Historische Kontextanalyse: Die Zeitreise

Der erste Schritt: Eine Zeitreise zum Ursprung des Softwareprojekts:

• Wann wurde das Projekt initiiert? Das Entwicklungsjahr gibt Aufschluss über den technologischen Kontext der Entstehungszeit. War Cloud Computing schon ein Thema? Welche Programmiersprachen waren damals üblich? Recherchieren Sie, wann das Projekt fertig geworden ist, wann mit der Entwicklung begonnen wurde oder wann die Idee dazu entstand.
• Welche Personen waren involviert? Die Suche nach Mitarbeitern, die damals bei der Entscheidung, beim Konzept und bei der Implementierung dabei waren, liefert wertvolle Einblicke in das "Warum" hinter technischen Entscheidungen. Möglicherweise finden sich auch Hinweise auf externe Entwickler oder involvierte Freelancer. Finden Sie diese Personen und ziehen Sie sie zu Rate!
• Welche Dokumente existieren aus der Entstehungszeit? Auch wenn keine vollständige Dokumentation vorliegt, können alte Meeting-Protokolle, E-Mails oder Projektpläne wichtige Hinweise liefern: Was war der Auslöser für das Softwareprojekt, welche Anforderungen wurden diskutiert? Werfen Sie einen Blick ins Archiv, alte Unterlagen oder Backups – der Aufwand lohnt sich!

Diese historische Einordnung hilft, Designentscheidungen nachzuvollziehen und den vorliegenden Code im richtigen Kontext zu verstehen. Oft stellt sich heraus, dass scheinbar irrationale Ansätze im Projekt unter den damaligen Rahmenbedingungen durchaus sinnvoll waren.

Beobachtung der Anwender: Die Praxis verstehen

Ein häufiger Fehler bei der Übernahme bestehender Softwareprojekte: Entwickler stürzen sich sofort auf den Fremdcode und versuchen, ihn zu verstehen – oft mit frustrierenden Ergebnissen, hohem Zeitaufwand und falschen Schlussfolgerungen.

In der Praxis ist immer wieder zu sehen, dass die wertvollsten Erkenntnisse nicht aus dem Code, sondern aus dem Verhalten der Nutzer kommen. Erst wenn wir sehen, wie Anwender mit dem System arbeiten und die Software in der Praxis nutzen, verstehen wir seine wahre Rolle im Unternehmen.

• Anwender bei der Arbeit beobachten: Wie nutzen die Mitarbeiter das System im Alltag? Welche Funktionen sind zentral, welche werden kaum genutzt? Welche Abläufe verursachen Frustration oder Zeitverlust?
• Etablierte Workarounds identifizieren: Oft haben Anwender kreative Lösungen für Systemschwächen entwickelt, die nirgends dokumentiert sind. Diese Workarounds zeigen nicht nur Problembereiche auf, sondern geben auch Hinweise darauf, welche Funktionen besonders wichtig sind.
• Ungeschriebene Regeln und Prozesse erfassen: Viele Arbeitsabläufe folgen Regeln, die nie formalisiert wurden, aber für den reibungslosen Betrieb entscheidend sind. Diese impliziten Regeln finden sich nicht im Code, prägen aber maßgeblich, wie das System genutzt wird.

Diese Phase ist entscheidend, um herauszufinden, welche Teile des Systems geschäftskritisch sind und welche Funktionen möglicherweise überholt sind oder verzichtbar.

Technische Analyse: Den Code strukturiert erfassen

Erst jetzt, mit dem nötigen Kontext- und Anwendungsverständnis, beginnt die eigentliche Code-Analyse des Legacy-Codes:

• Strukturierte Visualisierung: Mit Hilfe spezieller Tools wird die Architektur des Systems visualisiert, um einen Überblick über Module und deren Zusammenspiel zu gewinnen.
• Identifikation von Kernkomponenten: Welche Teile des Codes sind zentral für die Geschäftslogik? Welche Module sind besonders komplex oder fehleranfällig?
• Technische Schulden erkennen: Wo wurde aus Zeitdruck "unsauber" gearbeitet? Welche Bereiche des Codes sind besonders wartungsintensiv?
• Sicherheitsrisiken bewerten: Enthält der Code bekannte Sicherheitslücken? Werden veraltete Bibliotheken oder Frameworks verwendet?

Diese umfassende Code-Analyse des Altcodes liefert – im Kontext des vorher gewonnenen Wissens – ein vollständiges Bild des Systems und seiner technischen Qualität.

---

Code weiterentwickeln, portieren
oder neu entwickeln?

Nach Abschluss der gründlichen Analyse ist eine fundierte Entscheidung möglich, wie es mit dem Softwareprojekt weitergehen und der Code modernisiert werden soll. Grundsätzlich gibt es drei Optionen:

Bestehenden Altcode weiterentwickeln

Die Weiterentwicklung des bestehenden Softwarecodes ist wirtschaftlich sinnvoll, wenn folgende Faktoren zusammenkommen:

1. Solide Codequalität: Der Quellcode ist gut strukturiert, verständlich und wartbar. Die grundlegende Architektur ist stabil und erweiterbar.
2. Aktuelle Technologiebasis: Die verwendeten Programmiersprachen und Frameworks werden noch aktiv weiterentwickelt und unterstützt.
3. Modularer Aufbau: Das System ist in klare Komponenten gegliedert, sodass neue Funktionen ohne umfassende Änderungen integriert werden können.
4. Zuverlässige Kernfunktionen: Die zentralen Algorithmen und Geschäftsprozesse im Code arbeiten fehlerfrei und bilden eine verlässliche Grundlage.

Altcode auf neue Plattform portieren

Die Portierung auf eine neue technologische Basis ist der optimale Mittelweg, wenn diese Situation vorliegt:

1. Bewährte Geschäftslogik: Die im Code implementierten Fachprozesse und Algorithmen sind ausgereift und spiegeln wertvolles Unternehmenswissen wider.
2. Technologischer Stillstand: Die verwendete Plattform oder Programmiersprache wird nicht mehr unterstützt oder weiterentwickelt.
3. Hohe fachliche Komplexität: Die Geschäftslogik ist so spezialisiert und umfangreich, dass eine Neuentwicklung mit erheblichen Risiken verbunden wäre.
4. Integrationsbedarf: Bestehende Daten, Schnittstellen und angebundene Systeme müssen unbedingt kompatibel bleiben.

Software komplett neu entwickeln

Eine komplette Neuentwicklung des Softwarecodes ist die richtige strategische Entscheidung, wenn diese Faktoren überwiegen:

1. Grundlegende Konzeptionsschwächen: Das System wurde ursprünglich für andere Anforderungen entwickelt und lässt sich nicht sinnvoll an aktuelle Bedürfnisse anpassen.
2. Veraltete Technologiebasis: Die eingesetzte Technik ist so überholt, dass selbst eine Portierung keine zukunftsfähige Lösung darstellt.
3. Mangelhafte Codequalität: Der Altcode ist so schlecht strukturiert, dass die fortlaufende Wartung und Anpassung höhere Kosten verursacht als eine Neuentwicklung.
4. Veränderte Geschäftsanforderungen: Die Bedürfnisse des Unternehmens haben sich so grundlegend gewandelt, dass die bestehende Lösung nicht mehr passt.

---

Checkliste: Optimale Vorbereitung
für die Codeübernahme

Wenn Sie vor der Herausforderung stehen, ein bestehendes System von einem neuen Entwickler betreuen zu lassen, können Sie den Prozess durch eine systematische Vorbereitung erheblich vereinfachen. Wir helfen Ihnen dabei!

---

Fazit: Vom Problemfall
zum zukunftsfähigen Asset

Was zunächst wie ein undurchdringliches Labyrinth erscheint, lässt sich mit dem richtigen methodischen Ansatz in einen klaren Weg verwandeln. Die Übernahme fremden Codes ist keine Frage des Glücks oder der Intuition – sondern das Ergebnis systematischer Arbeit.

Der wesentliche Unterschied liegt im Vorgehen: Während viele sofort in den Legacy Code eintauchen, schauen wir zuerst auf den Menschen, den Kontext und die Geschichte hinter dem System. Diese ganzheitliche Perspektive ist der Schlüssel, der verschlossene Türen öffnet.