This book is a mega hit brought to you by Martin Fowler, Kent Beck, and other prominent individuals. Refactoring is not so much a construct of a certain programming language, but an approach, philosophy and discipline. William Opdyke defines it as “a way to restructure software to make design insights more explicit, to develop frameworks and extract usable components, to clarify the software architecture, and to prepare to make additions easier” (page 382). In essence, it is your ticket to maintainable code and healthy sanity. Oh, and you get to save your hair since you won’t be pulling it so much.
The book presents a “catalogue” of symptoms you might spot in your code as well as prescriptive guidance of dealing with them. Those who prefer reading code over academic ramblings will love this book: nearly every refactoring comes with a “before” and “after” code sample. The samples are in Java, but the choice of language is not the point here. It’s about recognizing where the code “smells bad” and changing it. Whichever language you do it in is of secondary concern.
The impatient and the doubting ones can kick back and watch Martin take a bulky code sample and turn it around rigt in Chapter 1.
I’ve mentioned this before—Martin’s books read like old friends. He’s a very insightful author who presents his ideas in very plain language and without jargon. In fact, having been developing software for over a decade, I found that most refactorings simply “made sense”, and I had been doing them already anyway. However his discussion of when, what and why refactor throughout the book is what makes it so valuable. Martin offers a plethora of great advice on why you need to refactor, what’s in it for you, when to begin and when to stop.
You may ask, How do I justify refactoring to my superiors? It’s a difficult question because many managers believe that your sole job is to write new code and it’s your fault if you need to take a detour. What were you thinking and why is the code so bad?
Here’s a piece of valuable advice:
You can adjust your system as time goes on. […] A good encapsulation six months ago may be awkward now. Refactoring means you never have to say you’re sorry—you just fix it.
Of course you will be adding new functionality, so take note of these words by Kent Beck:
You are likely to see new possibilities in your code, even if you have worked with it for years […]. You may even want to jump in and clean up every problem in sight. Don’t. No manager wants to hear the team say it has to stop for three months to clean up the mess it has created. And, well, they shouldn’t. A big refactoring is a recipe for disaster.
As ugly as the mess looks now, discipline yourself to nibble away at the problem. When you are going to add some new functionality to an area, take a few minutes to clean it up first. If you have to add some tests before you can clean up with confidence, add them. You’ll be glad you did. Refactoring first is less dangerous than adding new code. Touching the code will remind you how it works. You’ll get done faster, and you’ll have the satisfaction of knowing that the next time you pass this way, the code will look better than it did this time.
Do you need to ask permission each time you decide to refactor? No. Follow the advice above to the letter and you will learn to discipline yourself to sterilize code without changing its behavior.
Conclusion
I think Refactoring: Improving the Design of Existing Code should be on the bookshelf of every developer regardless of the platform and language choice. After all, refactoring is a frame of mind, not a technology.
