In 2000, Martin Fowler’s highly successful book on redesigning software — or, more commonly, refactoring — was published. Six years later, we could even hold the Hungarian edition in our hands, and by 2018, the book reached its second edition. The author also launched an online catalog, available at refactoring.com. All of this suggests that the topic attracts considerable interest, has become increasingly important in recent years, and remains very modern.
The idea of refactoring emerged as early as the 1990s. It appears among the principles of agile development and extreme programming. It has become an integral part of agile practices: we start coding with a simple structure, continuously write developer tests, and — supported by these tests — confidently reshape the parts written so far as new requirements arise. Of course, this requires a modern developer mindset and some practice as well.
At ponte.hu, we dedicated time and energy to the topic and examined it on multiple levels. We began with a general overview. What qualities do we want our code to have? Readable, simple, maintainable — to mention only the most important ones. In a single word, we could say: the code should be “clean.” We also discussed what happens when, for one reason or another, we cannot maintain this cleanliness. We explored the concepts of technical debt and software entropy. We recognized that both are inevitably present in software development. Both stem from the constant need for change — and change is part of our everyday reality. The correct approach is to account for it continuously. And if we want to keep our codebase intact despite frequent modifications threatening to pull it apart, we need a tool — a good practice. This is continuous refactoring.
Moving a bit closer to the topic, we looked at what rules guide us and when it is worth redesigning code. When we find ourselves making the same modification for the third time in a way we know could be cleaner? Before introducing new functionality into the system? After fixing some bugs? An experienced programmer instinctively knows the answers to these questions. We also assessed what level of discipline is needed to refactor in small steps. This is important because everyone can only perform modifications up to a certain complexity effectively. If we start with small steps, we will finish the task faster and also map out our own limits.
However, we spent most of our time doing what we enjoy most: coding. We went through the characteristics of “smelly” code — with Martin Fowler’s book helping us along the way. At each point, we examined which refactoring techniques could be applied effectively, and we tried them out. We learned how to counter code duplication, long functions, large classes, “lazy” (non-essential) or speculative code fragments. The concept of “shotgun surgery” has now been permanently burned into our long-term memory.
Prepared exercises supported our practice, which we solved in pairs, individually, or under the watchful eyes of others. We reviewed a total of 24 techniques over four sessions, spending around six hours on them. The whole experience felt like an adventurous journey — one that we would gladly have celebrated with a glass of champagne… though only outside working hours, of course.
We are aware that after just a few hours of focused work, we did not become experts in the field. However, each of us learned something — and in a way that has practical relevance in our everyday work. That was the goal… and we achieved it successfully.
"Mission completed." Or rather, in a more fitting style: "refactored."