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.