If you haven’t read the blogs about history of Refactoring Pyramid that help to keep Clean Code read below articles first.
How Pyramid of Refactoring was disovered?
How to clean code according to refactoring pyramid?
How SOLID Principles support refactoring?
Sometimes people ask the question why I’ve chosen the pyramid as a way in which I described my approach to refactoring.
There are many other concepts on how and when to refactor. Each of them makes it easier for us to change the Legacy Code into Clean(er) Code – based on different criteria and different perspectives.
Some approaches present a set of subsequent steps to perform in the right order, such as Natural Course of Refactoring designed by Mariusz Sieraczkiewicz from BNS IT. Other ideas are based on triggers that are suggesting refactoring in given situations, e.g. code smells. I recommend to read Smells to Refactorings Guide created by Joshua Kerievsky.
In turn, the author of the core book “Refactoring” – Martin Fowler presented the idea of “Workflows of Refactoring“. Martin looked at the issue from a more general perspective through the reasons when and why we should clean code. Here are examples : “refactoring to understand”, or “refactoring to be able to extend”.
However, I chose the pyramid (here is example of refactoring in Java language How to clean code according to refactoring pyramid? ) due to the following reasons.
Symbolism of foundations and work from scratch
Each lower level of the pyramid is the foundation for the upper level. This encourages you to perform activities in a specific order. It also emphasizes that accomplishment of previous activity will unveil new ideas. It triggers you to start work on the further transformations.
This also true within individual layers, which can be divided into even smaller ones. For example, the transformation “extract parameter” or “add parameter” will only take place after the “extract method” is performed and can be followed by “Introduce Parameter Object” if needed.
Activity frequency decreases as the level increases
Transformations from lower layers are performed much more often than transformations from higher layers. Basic transformations are automated in the IDE so they take literally seconds.
A similar situation takes place in the case of Testing Pyramid. Individual tests on the upper layers are less frequent, but each of them relate to a greater range of functionality.
Test pyramid support
The level of test coverage affects the range of code where we can make changes safely.
Sometimes we perform refactoring within one single class – a small unit test is probably enough in such a case. But very often refactoring covers a larger range of functionality. In this case component test or integration test covering a larger range of system becomes very useful.
Division into smaller and smaller independent pyramids
A layer-based approach to refactoring additionally supports solving code issues using “divide and conquer” idea. We do not need to make a complete cleaning within flow of given method based on the lowest layer of the pyramid.
Perhaps it is better if we divide the current logic into 2 or 3 parts and we clean only the part that is currently undergoing change and development. This approach also allows you to parallelize work and skip work on code that works and is not subject to change at the moment, so we will not invest time and money in it.
Sometimes we skip temporary cleaning the flow and extract a smaller method right away. Then later – at some point – we come back to cleaning this smaller method using code transformations from the bottom level of the pyramid.
