This is only one part of the book. Testing is coming up in Chapter 2.

There are many kinds of refactorings that can be done on a non-trivial project without significant amounts of testing. For example, you can safely replace new Integer(5) with Integer.valueOf(5) almost without reguard, unless the Integer is being used as a lock and it needs to be a unique object. Synchronizing on Integers is not overly common and it is something that you are likely to be aware of when changing some source code.

It really depends on the complexity of the refactoring. Using eclipse to rename methods is pretty darn safe. If something could cause overshadowing or a hiccup, eclipse has decent warnings. Or how about getting rid of System.out.println and replacing it with a logging facility? You need to decide on what kind of message is being written out. It is tedious and there is no real way to automate this change over. Out of the 1,000s of changes I made in moving our code base over to log4j, I’m not aware of any bugs introduced even after more than a year of it being in production.

I have done non-trivial refactorings and yes it does take time to both implement and fix everything that you might have broken. And I agree this kind of refactoring isn’t something that you will do in your random spare time. But I have a feeling the author is getting at the simpler kinds of refactorings.

However, I generally agree that simple refactorings can be done in your down time. It makes maintenance much easier. And it improves your own programming by pounding into your head not to do x, y, or z. I’m a proponent of refactoring code, especially code that you are intimately familiar with.

–
Simon