Refactoring vs. Rewriting: Why it matters

Refactoring vs. Rewriting: Why it matters

on Aug 31, 10 • by Eric Hollebone • with 3 Comments

As new words and concepts diffuse in to wider use, their definitions become simpler or broaden to cover more scope.  Like the kid’s telephone game, each time the concept is passed to another developer, the information gets a little more muddled. In software development, declaration, macros, syntax and other...

Home » Code Refactoring » Refactoring vs. Rewriting: Why it matters

As new words and concepts diffuse in to wider use, their definitions become simpler or broaden to cover more scope.  Like the kid’s telephone game, each time the concept is passed to another developer, the information gets a little more muddled. In software development, declaration, macros, syntax and other programming constructs have to be exact or the compilers will fail.  Yet, when developers discuss concepts about programming, most of the time, that precision of language is lost.

The telephone game  seems to have happened to refactoring.  I subscribe to what would be consider the  ”classic” definition of  refactoring: the process of optimizing or extending a class  but leaving the existing exposed interface alone.  It seems that refactoring has been generalized from that definition into covering all activities related to touching old code.  Even worse, it has become an excuse to rework someone else’s code and then bitch about how bad it was.  Just look at the twitter stream for refactoring for a never-ending torrent of  abuse.

There is one simple way to tell if your efforts are truly a refactoring or not.  Did you break any of the unit tests?  If you did, then you are rewriting code instead of refactoring it and you had better update all the test cases while you’re at it.  Don’t get me wrong, there are times to rewrite software, but they are few and far between and, in my experience, it almost never pays off.

Refactoring isn’t just a nice philosophical idea; it supports one the most basic concepts in software development–backwards compatibility.  If you want to keep your customers and enjoy that paycheck, don’t break features or APIs in products without good reason or  get buy-in before release day.

To refactor the medical phrase “First, do no harm“, for developers it should be “First, break no test”.

Related Posts

3 Responses to Refactoring vs. Rewriting: Why it matters

  1. Tools Insurance says:

    The blog “Re factoring vs. Rewriting: Why it matters” is so unique in itself..indeed Re factoring isn’t just a nice philosophical idea; it supports one the most basic concepts in software development backwards compatibility…nice to see this blog…thanks

    ***********

    james hawk
    Tools Insurance

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to top