As I get back into the swing of TDD, I'm rediscovering some of the things I didn't like about it first time round. While it's nice to have the rapid regression testing that it provides, I do worry about its effect on my code design.
When coding a lot of the rules for valid tile placement in Beaver, I started with simple test cases and worked my way up the complexity ladder. As I did so, the design of the production code became stretched to breaking point on more than one occasion. I ended up spending an inordinate amount of time refactoring and redesigning.
Sure, it was great that my encapsulation had shielded the tests from the changes I was making, but I felt frustrated at having led myself down so many dead ends. I wondered whether it wouldn't have been better to have done a bit more design up-front. As it was, my approach was killing momentum.
Still, I got through it. I'm left with code whose design still isn't brilliant, but it does the job reasonably efficiently. Next time, I'll not be such a slave to methodology. If I find myself coding things that probably won't stand the test of time, I'll just hack together some exploratory production code as quickly as possible and use it to decide on my direction. After which I can scrap/adapt it, and continue with TDD.
But what would you do? Has anyone out there reading this had similar experiences with evolving designs under TDD?
2 comments:
I've long felt that dogmatic adherence to "the simplest thing that could possibly work" is a sure-fire recipe to complex code, unnecessary refactoring and hobbled productivity.
For me this comes from some authors and consultants missing an important point of "agile", which is not that documentation,process and planning (etc.) are not important, they just aren't AS important as people, working software etc.
We don't do NO documentation - we do just enough. We produce what other people NEED (or we should).
Similarly favouring continuous design over BDUF doesn't mean you do NO design up front. That's just dumb. You just do ENOUGH design up front to make sure you heading down the right path, and no more.
Make sense, or am I talking bollocks (again)?
From where I'm standing, you're making a LOT of sense.
Granted, I'm still not going to produce much documentation for the projects I'm writing about here -- it's mostly scribbles on paper by my computer, seeing as I'm a one-man band -- but I'm not going to allow myself to be strait-jacketed by dogma either.
Post a Comment