Refactoring: The Good, The Sad and The Ugly
“Refactoring” is the practice of “improving the design of existing code without changing its behavior”. It’s an essential part of software maintenance. Done well, refactoring will make sure your code base is easy to maintain. Done poorly, refactoring will lead you into a dangerous swamp where you’ll be stuck forever.
Good: In order to really get the benefit from refactoring, I think we have to do it all the time. I resolve to always leave a code file in a state where I could be satisfied if I never got to improve it in the future. This works best on the micro-level: Before I jump to a different file, I check the naming, method lengths and formatting of my code. When done well, making the code better is part of writing the code in the first place. Sad: When I forget to follow this practice, or follow it poorly, I end up with codes in need of constant cleaning up. Creating new functionality feels like a drag, because there’s a lot of old junk I want to clean up before going on. It’s a sad day when I find myself cleaning up code that I really shouldn’t have to touch. Ugly: But if I skirt the sadness of improving code that I come across on my journeys, after a while, I’ll have a mess on my hands. If I’m lucky, I can fix this with a few checkins. Some projects seem to close down for weeks to “deal with technical debt”. In the worst situations, the code will be in a non-functioning state in the meantime. Or you may hear those dreaded words: “Rewrite from scratch”. If there’s one think I’ve learned, it’s to never leave the code in a non-functioning state. Once I depart from what I know work, getting back on track is many times harder than I ever imagined. When a project schedules “refactoring tasks”, I find myself sad. The need for scheduled refactorings is a symptom that we don’t do the necessary good or even sad refactorings as we should. And scheduling refactoring tasks is an excuse to perpetuate our bad habits.