Skip to content

How to Refactor Legacy Code

The topics Booleans, Conditions, Ifs, and Methods are most rewarding if you are working on a legacy project with tons of code that you cannot or do not want to change because they can be applied to new code without conflicts.

The topic Names is very demanding for legacy projects, as it may introduce a breach between old and new code, up to a degree where sections like Avoid encodings, esp. Hungarian notation and prefixes are better ignored.

Try not to mix different development styles within the same development object when carrying out a refactoring. If the legacy code contains only up-front declarations, and a complete refactoring into using inline declarations is not feasible, it is probably better to stick with the legacy style rather than mixing the two styles. There are several similar situations where mixing styles could cause confusion, for example:

  • Mixing REF TO and FIELD-SYMBOL when looping.
  • Mixing NEW and CREATE OBJECT when calling a CONSTRUCTOR.
  • Mixing RETURNING and EXPORTING in the method signatures of methods only returning / exporting one parameter.

We observed good results with a four-step plan for refactoring:

  1. Get the team aboard. Communicate and explain the new style, and get everybody on the project team to agree to it. You don’t need to commit all guidelines at once, just start with an undisputed small subset and evolve from there.

  2. Follow the boy scout rule to your daily work routine: always leave the code you edit a little cleaner than you found it. Don’t obsess with this by sinking hours into “cleaning the campsite”, just spend a couple of minutes extra and observe how the improvements accumulate over time.

  3. Build clean islands: from time to time, pick a small object or component and try to make it clean in all aspects. These islands demonstrate the benefit of what you’re doing and form solidly tested home bases for further refactoring.

  4. Talk about it. No matter whether you set up old-school Fagan code reviews, hold info sessions, or form discussion boards in your favorite chat tool: you will need to talk about your experiences and learnings, to enable the team to grow a common understanding.

From SAP/styleguides under CC BY 3.0 — more details
Last updated on