 |
Articles Feed |
Categories
Archives
- July 2010 (5)
- June 2010 (4)
- April 2010 (3)
- March 2010 (2)
- February 2010 (2)
- January 2010 (1)
- December 2009 (1)
- October 2009 (2)
- September 2009 (2)
- August 2009 (1)
- July 2009 (5)
- June 2009 (2)
- May 2009 (2)
- April 2009 (8)
- March 2009 (7)
- January 2009 (2)
- December 2008 (3)
- November 2008 (5)
- October 2008 (4)
- September 2008 (6)
- August 2008 (4)
- July 2008 (5)
- June 2008 (5)
- May 2008 (4)
- April 2008 (2)
- February 2008 (4)
- January 2008 (2)
- December 2007 (2)
- November 2007 (2)
- October 2007 (2)
- September 2007 (1)
- August 2007 (3)
- July 2007 (1)
- June 2007 (4)
- May 2007 (7)
- April 2007 (2)
- February 2007 (3)
- January 2007 (3)
- November 2006 (3)
- October 2006 (3)
- September 2006 (17)
- November 2004 (1)
Lessons of a Craftsman: Are you Test Driving, or just writing tests?
by: eric | January 7th, 2008 |
Recently I wrote the beginnings of a blackjack game in Java, and I found myself making what I believe is a common error. The Java gameplay mechanic uses a state machine to manipulate the deck. As I was implementing the state machine I found I needed a Card object, in addition to my Card3DObject which actually drew the card, a look-up table for the 3D cards, an interface for the Deck and an object representing the Deck (so I could mock it out), and when I came across the situation for an Ace I decided a needed an object responsible for computing a Total in order to handle the situation of an Ace being a 1 or 11.
Apparently an if statement would cause an irreversible hand cramp, ending my programming career.
If you’ve ever done the bowling game, and really why haven’t you, there’s more than a few ways to skin that particular cat. Ron Jefferies has done it about [four thousand different ways] (http://www.xprogramming.com/xpmag/index.htm), whereas Bob Martin typically teaches a simple one. While none of them are wrong, I’m partial to the Martin version because it’s a simple problem, and it deserves a simple solution. I can give that version to a college student, and he can understand it. Furthermore in that version the tests drive the design. Let’s go back and look at my blackjack game to see what I mean.
When writing the game I decided blackjack would be a FSM. I drew a couple of diagrams, then used the Java state machine generator to make my state machine. The problem, as I see it, is that I did this without writing a line of code. Furthermore as I was coding I was thinking two steps ahead, and making design decisions before I needed to. I did a mini-version of the BDUF, and it’s something I see people do all the time. I was writing test first but I wasn’t always letting tests drive that design. Frankly that’s not necessarily a bad thing, and virtually all large systems need some design as a sort of guide, but what I should have done is wait until the code forced me into the state machine, forced me into other objects, etc. It’s not the end of the world, and in the end I may even have made the same decisions I would have anyway, but given that I didn’t let my tests drive my design I probably won’t end up with the simplest thing that could possibly work. That’s a shame.