Bestehende Software verstehen, bevor du sie änderst
Ein bestehendes Softwaresystem verstehst du für eine Änderung, indem du von diesem Eingriff aus seine relevanten Abhängigkeiten untersuchst. Code, Konfiguration und Laufzeitbeobachtungen liefern Hinweise. Gespräche mit den Menschen, die das System betreiben und nutzen, klären ihre Bedeutung. Dabei entsteht ein begrenztes, überprüfbares Bild dessen, was betroffen sein könnte.
Wie viel Unterschied das macht, zeigt ein gedankliches Beispiel: Du sollst eine Tabelle vereinfachen. Zwei Felder werden durch eine neue Struktur ersetzt. Das Backend lässt sich überschaubar anpassen, die Tests laufen, und im Architekturdiagramm steht eine vertraute Folge: Frontend, API, Datenbank.
Du bist fast fertig. Dann fragt jemand aus dem Betrieb, ob der Monatsbericht die alten Felder noch braucht.
Der Zusammenhang liegt außerhalb deines Ausschnitts
Vom Monatsbericht steht nichts im Ticket. Eine Suche im Repository findet keinen passenden Zugriff. Trotzdem zeigt dir der Kollege einen geplanten Job, der direkt aus der Datenbank liest. Sein SQL liegt in einem anderen Projekt. Die Anwendung kann nach deiner Änderung korrekt funktionieren, während dieser Job fehlschlägt oder andere Zahlen liefert.
Jetzt wirkt der ursprüngliche Auftrag größer. Du könntest anfangen, sämtliche Repositories zu lesen. Nur würde selbst das die Frage offenlassen, wer die Ergebnisse verwendet und welche Bedeutung die beiden Felder dort haben.
Der hilfreiche nächste Schritt ist konkreter: Du verfolgst den Weg dieser Daten. Welche Prozesse schreiben sie? Welche lesen sie? Werden die Werte kopiert, umbenannt oder zusammengefasst? Und an welcher Stelle muss eine Aussage nach der Änderung weiterhin stimmen?
Der Bericht führt dich dabei zu einer fachlichen Frage. Bedeutet sein Feld „Abgeschlossen“ den heutigen Auftragszustand oder den Zustand am Monatsende? Ein technisch korrekter Ersatz kann diese Unterscheidung verlieren. Erst mit dieser Information lässt sich beurteilen, was der neue Aufbau erhalten muss.
Architecture Recovery beginnt bei vorhandenen Spuren
Das Rekonstruieren vorhandener Architektur wird als Architecture Recovery oder Architecture Reconstruction bezeichnet. Dabei werden Informationen aus einem bestehenden System zu verständlicheren Architektursichten zusammengeführt. Eine Fallstudie des Software Engineering Institute zeigt diesen Weg von extrahierten technischen Informationen zu Komponenten und ihren Schnittstellen. Das Grundproblem existiert also lange vor heutigen Modernisierungswerkzeugen.
In deinem Fall entsteht zunächst ein Dependency Mapping: eine Übersicht der für die Tabellenänderung relevanten Abhängigkeiten. Du brauchst dafür noch keinen vollständigen Plan der gesamten Anwendung. Schon eine nachvollziehbare Verbindung zwischen Tabelle, Import, API und Berichtsjob verändert den Untersuchungsumfang.
Statische Codeanalyse (Static Code Analysis) kann Verbindungen sichtbar machen, ohne die Anwendung auszuführen. Ein Call Graph beschreibt beispielsweise Aufrufbeziehungen. Seine Aussage hängt allerdings davon ab, wie Aufrufe bestimmt werden. Die CodeQL-Dokumentation zum Call Graph erklärt unter anderem die Unterscheidung zwischen statischen Zielen und polymorphen Aufrufen. Ein automatisch erzeugtes Ergebnis braucht Interpretation.
Beim Reporting hilft dir ein Call Graph des Backends ohnehin nur begrenzt: Der Zugriff beginnt in einem anderen Prozess. Deshalb gehören in diesem Beispiel auch Job-Konfigurationen, Datenbankberechtigungen und die Abfragen des Berichts zur Untersuchung. Ein technisches Werkzeug beantwortet jeweils einen Teil der Frage.
Ein fehlender Treffer ist noch kein fehlender Zusammenhang
Du schaust in vorhandene Zugriffsprotokolle. Dort findest du den Reporting-Job. Das belegt eine Nutzung im beobachteten Zeitraum. Wenn ein weiterer Job dort nicht auftaucht, bleibt zunächst offen, ob er ungenutzt ist, seltener läuft oder von dieser Protokollierung überhaupt erfasst wird.
Gerade bei gewachsener Software lohnt es sich, diese Unterschiede festzuhalten. „Liest laut Konfiguration aus Tabelle X“ sagt etwas anderes als „hat gestern aus Tabelle X gelesen“. „Nach Aussage des Betriebsteams abgeschaltet“ ist ein anderer Beleg als eine entfernte Berechtigung. Jede Aussage kann hilfreich sein, solange ihre Grundlage erkennbar bleibt.
Deine Notizen müssen dafür kein aufwendiges Inventar werden. Beim Berichtsjob stehen die konkrete Abfrage, die verantwortliche Person und die offene Frage zur historischen Bedeutung. Beim alten Export steht, dass seine weitere Nutzung noch geklärt werden muss. So kann jemand deine Schlussfolgerung prüfen, ohne deinen gesamten Suchweg zu wiederholen.
Diese Arbeit bereitet eine Impact Analysis vor: Welche Folgen könnte der geplante Eingriff haben? Die gefundene Verbindung allein ist noch keine Antwort. Entscheidend ist, was sich entlang dieser Verbindung verändert.
Wann du genug weißt, um weiterzuarbeiten
In unserem Beispiel stellt sich heraus, dass der Bericht den Zustand zum Stichtag benötigt. Das neue Feld bildet dagegen den aktuellen Zustand ab. Damit ist eine entscheidende Annahme des ersten Entwurfs widerlegt. Ein bloßes Umbenennen der Spalte würde die fachliche Aussage verändern.
Du kannst jetzt einen Übergang planen: Die bisherige Information bleibt so lange verfügbar, bis der Bericht auf eine passende historische Datenbasis umgestellt und fachlich geprüft ist. Welche technische Form das bekommt, hängt vom System ab. Die Begründung für den Übergang ist bereits klar.
Für den Prüfzeitpunkt reicht ein erfolgreicher Tageslauf nicht aus, wenn die kritische Nutzung erst zum Monatsabschluss stattfindet. Ihr braucht einen geeigneten Testfall mit bekannten Erwartungen oder einen kontrollierten Vergleich. Außerdem muss jemand die Bedeutung der Ergebnisse beurteilen können.
Die Untersuchung kann für diesen Eingriff enden, sobald die relevanten Datenwege, die zu erhaltenden Aussagen und die verbleibenden Unsicherheiten benannt sind und ihr ihren Umgang verantworten könnt. Bei unbekannten Lesern einer gemeinsam genutzten Datenbank kann das Ergebnis auch lauten: Die alten Felder lassen sich jetzt noch nicht sicher entfernen. Diese Grenze spart eine vorgetäuschte Freigabe.
Zurück zum ursprünglichen Ticket
Aus der vermeintlichen Feldbereinigung ist ein überschaubarer Übergang geworden. Im Ticket steht jetzt, welche Nutzung erhalten bleiben muss, wer sie prüft und welche Voraussetzung vor dem Entfernen der alten Struktur erfüllt sein muss. Dein Wissen lässt sich weitergeben.
Die Verbindung zwischen technischen Details und ihrer Wirkung steht auch in THINK FIRST Individual im Mittelpunkt. Die Lektion „Wie ein Systemmodell Abstraktion ermöglicht“ behandelt unter anderem einen Reporting-Zugriff, der in einer vereinfachten Sicht fehlt. Der Lernansatz hilft dabei, relevante Zusammenhänge für Entscheidungen sichtbar zu machen; eine Schulung in Analysewerkzeugen ist damit nicht gemeint.
Wenn diese Zusammenhänge später mehrere Menschen nutzen sollen, stellt sich die nächste Frage: Welche Darstellung hilft ihnen dabei? Für dein heutiges Ticket zählt zunächst etwas sehr Konkretes. Du kannst sagen, warum der Eingriff größer war als sein Diff – und welche Information nötig war, um ihn sinnvoll zu begrenzen.