Refactoring von Legacy-Code

Was du vorbereiten solltest

• Den kleinsten Codeausschnitt, der die relevante Fachregel vollständig enthält, inklusive globaler Daten, Includes oder Hilfsmethoden, falls sie tatsächlich gelesen oder verändert werden.
• Eine Refactoring-Absicht, zum Beispiel `Preislogik kapseln`, `Datenzugriff trennen` oder `FORM-Routine in testbare Klasse überführen`.
• Bekannte Invarianten: welche Ausgabe gleich bleiben muss, welche Tabellen verändert werden dürfen und welche Seiteneffekte bewusst bestehen bleiben.

Empfohlener Ablauf

1. Kontext bereitstellenStelle den zentralen Report oder die relevante Klasse bereit. Ergänze angrenzende Includes nur, wenn sie für die Logik wirklich benötigt werden; zu viel Kontext macht die Schnittkante oft unklarer.
2. Aufgabe konkret formulierenBeschreibe das Refactoring-Ziel technisch präzise: Verantwortlichkeiten schneiden, Seiteneffekte sichtbar machen, testbare Klassen oder Methoden vorbereiten und vorhandene Aufrufer möglichst stabil halten.
3. Änderungen prüfenPrüfe Methodensignaturen, Datenfluss und fachliche Gleichwertigkeit. Refactoring sollte in kleinen Schritten übernommen werden; ein großer, semantisch gemischter Patch ist schwerer zu validieren als zwei kleine.

Beispiel-Prompt

Der Prompt sollte bestehendes Verhalten schützen und den Änderungsumfang begrenzen.

Analysiere ZREP_LEGACY_ORDER_RUN und die enthaltenen FORM-Routinen.
Extrahiere die Preisermittlung in eine testbare Klasse ZCL_ORDER_PRICE_CALCULATOR.
Behalte das fachliche Verhalten bei und erstelle eine ABAP Unit Testklasse für die Kernfälle.

Review-Checkliste

• Bleibt die Reihenfolge fachlich relevanter Prüfungen und Datenänderungen erhalten?
• Sind neue Klassen und Methoden nach Verantwortung geschnitten statt nach zufälligen Codeblöcken?
• Decken die Tests die extrahierte Logik ab, ohne nur die aktuelle Implementierung nachzubauen?