The value of Continuous Refactoring

Refactoring is one of those skills that programming classes tend to ignore.

But everyone has to refactor code. Refactor is evening one of the stages of the TDD cycle: Red, Green Refactor. So, if refactoring is that important, why it is a skill that we should learn by ourselves? Why we leave the job to benevolent Senior Developers in our teams? Why we approach it as a skill that will come through experience? As a skill that doesn't require training?

For sure is something that experience will bring. But we are responsible for making it a structured practice since the early days. And that requires learning. Learning code smells, refactoring tactics, best practices, etc.

Otherwise, most of the times someone refactors the code, they are just re-writing it differently, not better. But, more important than knowing it or following the techniques, is to make it a habit. Refactoring should be part of the job. It shouldn't be an occasional task. Something that you do when everything seems messy.

If we keep the house arranged every single day, the job becomes easy. What takes more time? Keeping the house in order as we go or tidying up once a month?

We should aim for a continuous refactoring practice.

Nevertheless, sometimes the codebase can be in bad shape. On those cases, we need to push harder in the beginning. When the task seems impossible, there's nothing better than being bold. Otherwise, we may not be able to create a habit, because every time you want to do something, it will be too painful.

The results of starting big and painful refactor may be what you need to see the value of keeping the house clean.