When refactoring isn't
Probably the most frequent question that my consulting clients and prospects ask is “Should we rewrite this app or refactor it?”
This is an age old question.
But if I was going to be facetious, my answer would be “Yes and yes.” (I would never reply like this to a client, because, frankly, I don’t want to come across like Comic Book Guy from the Simpsons.)
These are not two diametrically opposed alternatives. They operate at completely different levels. One is a strategy and the other is a tactic.
Refactoring, as Martin Fowler puts it, is:
…a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which is “too small to be worth doing”.
For many languages, individual refactorings follow a clear pattern, and can be automated in code editors.
The light bulb came on for me when I finally started really trying to get better at test-driven development. In TDD, refactoring is a crucial part of the rapid cycle of red-green-refactor. First write a test that fails. Then write the quickest implementation you can to have the test pass, and finally, relentlessly refactor the code you’ve written. In practice, the refactoring part is often most of the work. And it’s something you do all the time.
Programming is much more about refactoring than it is about writing, much like writing is really much more about editing.
But many people use refactoring to also mean a planned programme of work to transform a code base or product from the inside out, without starting from scratch.
This is far from the ongoing, controlled, pattern-based approach described by Fowler.
Let’s be very clear, this kind of ‘refactoring’ also constitutes a rewrite of your application. It’s just that you’re using a different tactic for the same strategic aim.
You can rewrite by starting from scratch and deliberately ignoring all that existing code you have lying around. Or you can rewrite by reworking and modifying existing features, and moving them gradually to a design that’s easier to support and maintain. Or you can do a bit of both.
I’m not normally pedantic about how we use language in technology, but in this case it can be a big source of confusion, and the cost of talking at cross-purposes can be high when you’re considering fundamental change in a web app!
All the best,
– Jim
