ChessTDD 12: Blind Alleys
This is one last post of loose ends and looking at what I’ve done so far before I move on to new functionality. It wasn’t necessarily my finest hour as a programmer and TDD practitioner, but I’m including the good with the bad because nobody is always on when programming. Also, I wasn’t insanely on in terms of my audio recording either becasue my throat was a little scratchy today. You might hear me stealing quiet sips of ice water from time to time. Anyway, here’s what I accomplish:
- Reworked the knight’s GetMovesFrom() method
- A fair amount of design flailing
Here are some lessons to take away:
- An interesting side effect of a long time spent at TDD is a tendency to look to unit tests when wanting to dive into and explore code functionality. The reason for this is that you know the unit tests will show you how the class’s public API is being used. So, it’s like finding the class instantiated in-situ in the code, except that in the test class, it’s going to have a bunch of methods with descriptive names telling you how things work.
- When doing exploratory refactorings, try to keep things compiling as much as you can and check with as much granularity as possible that you’re still passing. Some of my flailing with tuples of ints wasn’t really necessary, but I kept my eye on the tests anyway so as not to get stuck in the middle of a refactoring where tests are red, things are broken, and I don’t know how to go forward or back.
- Check out around 9:50. Copy and paste will always burn you. Even when it’s tiny. Even when you’re using TDD.
- Sometimes you wind up in a blind alley. That’s okay. Go back to where things were working and tackle the problem again later. This isn’t just punting; it’s an important skill. You need to ship code and you can get lost in trying to perfect it if you aren’t careful. So, let it go, think on it later — in the shower or while eating dinner or something — the answer will smack you in the forehead like a ton a bricks at some point.
[…] ChessTDD 12: Blind Alleys – Erik Dietrich continues with his series of posts looking at creating a Chess game using Test Driven Development techniques. This post continues the rounding up of odds and ends before moving on to new functionality […]
There are two types of coders: those that are chuckling, thinking of the day (or more) they spent doing what you did in this one… and liars.
From those of us who haven’t ever engaged in pair programming and occasionally harbor the delusion that “I am the only one who flails around uselessly in my code”, thanks for this ep. Lesser teachers would delete it and pretend it never happened.
Thanks for the kind words, and it’s really, honestly good to know that this sort of thing is appreciated. I questioned whether to do this myself — not out of pride, but weighing whether the “everyone screws up and that’s normal” lesson was worth the floundering and not particularly helpful coding in the clip. It’s nice to see a vote to say that it was. Thanks.