Refactoring

Frank Buschmann wrote a 2-part article in the July/August and September/October issues of IEEE Software that covered an important aspect of software development: refactoring.

Yes,  you’ll hear the word “refactoring” spoken often in any development team, but most developers rarely discuss what refactoring is, and whether they are refactoring or doing something else, like “reengineering” or even re-writing.

I won’t repeat what Frank said, as he said it quite well,  but as I read the article I realized that there are some points that get lost in many teams and are worth emphasizing:

• Refactoring does not mean “any kind of changing.” It means changing the structure of existing code to preserve functionality. In principle you are making the code “better.”
• To refactor you need a way to validate that you have preserved functionality. Automated tests are probably the best way to do this. I suggest that you can’t refactor without having a test plan in place. And from a practical perspective, this means automated tests.
• Refactoring is a way to improve code quality, but like other things a development teams spends time on,  you you should refactor when it provides business value. 

Being precise about when a change is refactoring and when it’s reengineering, a rewrite, or simply changing code to add a feature helps set expectations with stakeholders and helps you as a developer better understand when you’ll be done. And by thinking in terms of refactoring continuously you can deliver code more quickly, and avoid the need for reengineering or re-writing, and better be able to evaluate functionality with incremental delivery.

Refactoring is good. Not all good coding is refactoring.