Refactoring legacy code

What to prepare

• The smallest code slice that fully contains the relevant business rule, including global data, includes, or helper methods if they are actually read or changed.
• A refactoring intent such as `encapsulate pricing`, `separate data access`, or `move FORM routine into a testable class`.
• Known invariants: which output must stay identical, which tables may change, and which side effects intentionally remain.

Recommended workflow

1. Provide contextProvide the central report or relevant class. Add adjacent includes only when they are required to understand the logic; too much context often makes the seam less clear.
2. Describe the task preciselyDescribe the refactoring goal precisely: cut responsibilities, make side effects visible, prepare testable classes or methods, and keep existing callers as stable as possible.
3. Review the changeCheck method signatures, data flow, and functional equivalence carefully. Refactoring should be accepted in small steps; one large semantically mixed patch is harder to validate than two small ones.

Example prompt

The prompt should protect existing behavior and limit the change scope.

Analyze ZREP_LEGACY_ORDER_RUN and its FORM routines.
Extract price calculation into a testable class ZCL_ORDER_PRICE_CALCULATOR.
Keep the business behavior unchanged and create an ABAP Unit test class for the core cases.

Review checklist

• Does the order of relevant validations and data changes remain intact?
• Are new classes and methods cut by responsibility rather than by arbitrary code blocks?
• Do the tests cover the extracted logic without merely duplicating the current implementation?