Refactoring: Step back to definition

Arnon Gal-Oz, an absolute rock star of software engineering, cautioned me with regard to the common misconception of refactoring. His point is well taken, especially since the misconception was one I held for a couple of years, before I stumbled upon the correct (and far more useful) definition.

In short, refactoring is not rewriting, nor is it intended to fix bugs or optimize code. Of course it might, as a side affect, but I think it’s far better to entirely ignore those otherwise laudable goals when one refactors.

Refactoring is quite simply imposing good, or even just better, design on existing code. Period. Full stop. End of sentence…it would make a good telegram, wouldn’t it?

For something so simple it’s surprisingly powerful, not to mention cost effective. It can even save on psychiatric bills. Really! :-)

It’s powerful because changes are made using a known methodology in small steps within a framework of continual tests. Since the code worked before you started, and since you will have tests to run at each step, you will know immediately when a change has gone wrong and what is at fault.

It’s cost effective because it makes changing features or behavior easier to implement and since you’ll already have a good test for the refactored code, changes will be easier to test. You really will spend less time debugging new code or new bugs later if you refactor now, even if you don’t have an immediate need to do any new programming right away.

Even better you can start small and convince yourself. You might even be fortunate to work in an environment that has automatic refactoring such as Java. But the benefits still apply to those of us who have do manual refactoring.


6 thoughts on “Refactoring: Step back to definition

  1. Nancy,

    Have you checked out the Code Analyst tool for SednaX and some of the rules in there?

    I would be especially interested in your thoughts on what other rules should be included.

  2. Nancy! There you are!

    So, you’re finally blogging, I see… (and well, I might add). I suppose that leaves me as the last existing old-timer (which probably means I’m next).

    Your comments on refactoring are insightful, spot on, and almost disturbingly timely for me. I started a new job recently, where my first task is to transition the entire corporate enterprise from SQL 6.5(!) to SQL 2005.

    Oh, the fun I’m having!

    Anyway… Nice to see you on the soapbox. :-)

  3. Hi, Andrew-

    Thanks for writing. I haven’t had a chance to do anything with SednaX yet, but your post has prompted me to put it on my to do list! Thanks.

  4. Devin! Hey, love. Glad to hear from you. I’ll be fascinated to hear how your project goes. Especially whether you find that rewriting or refactoring is the better approach, or if you use a combination. (P.s. you and the family should come to Seattle sometime!)

  5. Looks like this is where the cool kids are now ;)

    The more I see the emphasis of refactoring as a tool for “polishing design” rather than specifically for bug fixing or optimization, the happier I am.

    Like Devin, I too recently started a new job and I am involved in the refactor vs rewrite conversation that needs to take place. I’m dealing with a 750k+ LOC ASP.NET app that was a direct port from a ColdFusion app by ColdFusion developers with no .NET experience. We’ll see how that works out.

Comments are closed.