The following is a post I made a number of months ago on the old blog. I thought I’d repost it here. Lately it’s been on my mind again.
I consider myself a refactoring junkie. Anytime I look through any amount of code I am always watching for code duplication, unnecessary code, complicated methods, bad variable names, etc. There is no real method to how I go about it. I usually start somewhere and see what I can find. It’s the old sweater syndrome — pull one thread and see what unravels.
However, in order to be so cavalier in refactoring, there has to be something there to back me up. The most frequent back up is the compiler. I can refactor left and right, changing things that will cause compiler problems. Then I just move through the compilation errors and take care of them. But the best insurance policy are unit tests. Of course, that assumes they are present…
Unfortunately, the need to get my refactoring fix doesn’t always go over so well with other people. “You want to do that now?”, or “yes, it needs to be done, but we have a deadline to meet” are frequent reactions. Most of the time I think it is just fear. And even when there are unit tests, there’s still fear.
So my advice to everyone:
- Refactoring is good. If you’re not skilled at it, there are many resources. I’d suggest Martin Fowler’s Refactoring, or Kent Beck’s Test Driven Development as good resources.
- Use the IDE. Eclipse and IntelliJ are both very good with refactoring code and showing where code can be fixed.
- Two minds are better than one — pair programming on refactoring is often very beneficial.
- Bottom line… try it! That’s what CVS is for! Change the code and try it out. You can always revert to the old stuff.







