Refactoring in Tunes

[Jim Little]

btanksley@hifn.com wrote:
> A professional discussion of refactoring (the definition I'm using) is
> available at http://xprogramming.com, and is discussed at length in Martin
> Fowler's "Refactoring: Improving the Design of Existing Code", ISBN
> 0-201-48567-2.  I cannot recommend this book highly enough; it has changed
> the way I code and design.

I have to second this recommendation.  This refactoring book is quite
simply the best "how to" manual for code I've ever seen.  Ostensibly
about how to refactor, it's also the best set of examples of quality
code I've seen.

To help clear up some of the misconceptions about refactoring I've seen
in Brian and Laurent's posts: refactoring is not about breaking code
down into the smallest meaningful pieces, although that can be a useful
application of refactoring.  Rather, as I believe Billy mentioned,
refactoring is about changing the design of the code without changing
the semantics of the code.  In practical terms, you refactor any time
you need to modify a piece of code and the existing design doesn't allow
you to do so cleanly.

Martin Fowler's "Refactoring" book defines it thusly:

"
Refactoring is the process of changing a software system in such a way
that it does not alter the external behavior of the code yet improves
its internal structure.  It is a disciplined way to clean up code that
minimizes the chances of introducing bugs.  In essence when you refactor
you are improving the design of the code after it has been written.
"

Brian, you appear to be talking about something else, though I'm not
sure what.  I'm not trying to nitpick you away from your point, but for
the sake of clarity I thought it was worth discussing the definition
further.

Jim