In both cases, you are doing the exact same thing in terms of the code: you’re replacing the existing code with something altogether new, which renders the code inoperable (un-compileable) for an extended period of time and which must, in the end, be re-validated to verify that the new code works the same as the old.

In my prior message, I mentioned that refactoring is a transformation without breaking the system. BrowserUk mentions later in this thread that refactoring is an iterative process, and he's spot on. For example, if I inherit a chunk of code with a mess of global variables and procedural functions and I want to transform it into an object-oriented system, then I'll do it stepwise with the system working after each step.

First, I may decide to group related variables together into their own namespaces. So I'll create a new module for the new namespace, and put the variables in it. Then I'll update all the references to the variable to the new namespace. Then compile and test it. Then I'll move the functions appropriate to that namespace into the new modules, compile and test. After each individual step, the system still runs.

It's true that the system needs to be revalidated after you're done. But you should maintain the system in working order throughout the process. If revalidation fails, then it indicates a failure of your test suite/data to cover all cases. So be sure to update your tests, too! Since you're doing it one step at a time, it's pretty easy to cruise through many iterations in a day. No iteration is drastically different than the one before it, but if you know where you're going, then your initial state and end state will be dramatically different.

I could go on, but better authors than me have covered it well:

• http://c2.com/cgi/wiki?WhatIsRefactoring
• http://www.refactoring.com/
• http://martinfowler.com/distributedComputing/refactoring.pdf
• http://sourcemaking.com/refactoring

...roboticus

When your only tool is a hammer, all problems look like your thumb.