What is Refactoring?

Reasons for refactoring

What are the two main reasons for the need for refactoring? The answer is:

• Complexity and
• technical debt.

In 1980 – before the term refactoring was used – Meir “Manny” Lehmann, a German professor and head of the Computing Department at Imperial College London, wrote: “As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it”.³

And Ward Cunningham, one of the 17 authors of the Agile Manifesto, used the so-called “debt metaphor” to emphasise the importance of refactoring in the course of eliminating technical debt: “With borrowed money you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it”.⁴

Goals of refactoring

Basically, refactoring addresses two concrete goals:

• Increasing the performance of the software.
• Facilitating the advancement of the software.

In the literature and numerous articles additional/other goals are often mentioned:

• legibility,
• clarity,
• extensibility,
• comprehensibility and
• testability.

Of course, structural clarity is desirable, as is legibility or comprehensibility. However, the extensibility and testability must be emphasised as they directly address the increase in performance and facilitate the ongoing development of the software.

Procedure for refactoring

The goals are achieved by

• the maintenance and improvement of draft and design. This improves both the clarity (e.g. by modularizing the software) and the extensibility and testability.
• The optimisation of the code – on the one hand in the sense of using new, better, faster or more robust programming languages, libraries, widgets etc., and on the other hand in the sense of legibility and comprehensibility.
• The elimination of code smells such as code duplicates. Even if the elimination of concrete errors is not a primary goal of refactoring in itself, errors in the code are discovered again and again in the course of software restructuring. Of course, depending on severity, priority and effort, these should be eliminated quickly. The processes for bug fixing in companies often vary.

A big advantage results from the mentioned goals: An improved structure allows extensions to be implemented more quickly as a result. In other words, the development speed increases. And this also reduces the costs of development in relative terms.

Challenges in refactoring

Possible challenges or disadvantages are considered to be:

• The accidental implementation of unwanted changes or errors. Even seemingly small changes can have a big impact. Unit tests can reduce this risk.
• The effort could be greater than originally expected or planned.
• The coordination effort between developers and/or software architects may be greater than expected.
• The customer doesn’t notice anything about the refactoring, because everything feels unchanged to him and he doesn’t get any new features.

Nowadays refactoring is a central component of iterative software development. In this context, we also like to talk – in contrast to selective, unique approaches – about continuous restructuring.

There are different opinions in the practice of software development on the topic of “uncompromising” refactoring; should time for refactoring be planned in every sprint in the course of an agile procedure and therefore new features be temporarily dispensed with, or do new customer requirements or features take precedence? The metaphor of the two hats goes back to Kent Beck, the inventor of extreme programming:⁵

• If new functions are added, existing code must not be changed.
• If a software is restructured, no new functionality may be added.

Impulse to discuss:

Refactoring is also recommended as one of 23 practices when implementing Clean Code. How important is refactoring compared to the other 22 practices?

Notes:

[1] Proceedings of Symposion on Object-Oriented Programming Emphasizing Practical Applications. Refactoring: An aid in designing application frameworks and evolving object-oriented systems.
[2] Martin Fowler: Refactoring: Improving the Design of Existing Code
[3] Meir “Manny” Lehmann: Laws of software evolution revisited, https://link.springer.com/chapter/10.1007/BFb0017737
[4] Ward Cunningham: Debt Metaphor
[5] The “Two Hats Metaphor” by Kent Beck can also be found in Martin Fowler’s refactoring book.

William Opdyke received his doctorate on the subject in 1992: Refactoring Object-Oriented Frameworks

Martin Fowler mentions a number of refactorings, such as

• Composing Methods,
• Moving Features between Objects,
• Organizing Data,
• Simplifying Conditional Expressions,
• Making Method Calls Simpler and
• Dealing with Generalization.

Here you will find a good overview of various refactorings.

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.

Here you can find additional information from our t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.