What is Refactoring, which goals are pursued and what are the challenges?
The restructuring of software
Software development is a continuous process. As soon as a company has released a new version of a software, users demand new requirements for new versions. Over time, the range of functions grows, but the more extensive and older a software and its architecture gets, the more difficult the further development becomes. Here the so-called Refactoring helps. It describes the – manual or automated – restructuring of a software (mostly) while maintaining the functionality.
The term Refactoring was first mentioned 1990 by the US-American computer scientists Ralph Johnson and Dr. William Opdyke. Through Marin Fowler’s book “Refactoring: Improving the Desgin of Existing Code”, in which Dr. Opdyke also participated, the term and the techniques of refactoring spread very quickly among software developers.
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:
- comprehensibility and
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.
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.
You will find a good overview here »