TITLE: TDD and Refactoring
AUTHOR: Eugene Wallingford
DATE: August 02, 2004  8:27 AM
DESC: miscellaneous notes
-----
BODY:
As I prepare my
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2004-07.html#e2004-07-29T08_15_20.htm">upcoming tutorial on test-driven development</A>
for
<A HREF="http://sugarloafplop2004.ufc.br/">SugarLoafPLoP 2004</A>,
I find myself frequently coming back to the idea of refactoring and
its synergy with TDD.  Fortunately, there will also be a tutorial
on refactoring at SugarLoafPLoP, by Joe Yoder.  I think that our
tutorials will be able to work together, too, to help folks see
that, to get full benefit of either, one really ought to practice both!

That isn't to say that one can't do test-driven development alone.
My coding practice in interactive languages like Scheme and Smalltalk
have always been test-driven, because it's so easy to build a test
suite and the desired code in parallel.  On the other hand, in a
language like Java, it's so easy to get caught up in the details of
a big class and lose sight of the tests.  This is where I find that
having cultivated TDD as a practice has has made me a better
programmer.

Jason Marshall recently wrote a nice piece on
<A HREF="http://www.jroller.com/comments/jdmarshall/Weblog/the_exponential_nature_of_lines">the value of refactoring</A>.  He says,

<BLOCKQUOTE>
... on my most productive day of coding ever, I had written negative
500 lines of code.  On my longest sustained 'productive' cycle, on
the first project I mentioned, I averaged negative 200 lines of code
for four weeks ...
</BLOCKQUOTE>

This reminded me of one of Brian Foote's wonderful aphorisms: "The
only thing better than a 1000-line of code weekend is a minus
1000-line of code weekend."  Of course, it's sometimes hard to
convince anyone still living in a LOC world to appreciate the value
in your accomplishment!

Anyone who has had to live with an out-of-control code base understands.
Jason's article explains well the value of refactoring even in the
absence of any other agile practices:  Repetition, especially the
mindless sort, ultimately makes the code too big and too hard to
understand.  That makes it hard for anyone to add to the program.
-----