Chess TDD 22: Friendly Pieces
This episode saw me make the first distinction between friendly and enemy pieces in determining available moves. It had also been a while since I’d worked on the series, so I was a little uncomfortable with how well I was reasoning at compile time about what was happening. The Board class and some of my implementations are getting a little awkward and I’d like to spiffy them up. However, I think that I’m going to start focusing on writing acceptance tests right now to bolster the correctness of what’s going on. This will allow me to separate fixing any flaws in my reasoning from making the code more readable, which really are two separate things.
Here’s what I accomplish in this clip:
- Stopped knight from being able to land on friendly pieces
- Implemented the concept of capture
- Stopped allowing jump of any pieces for the purpose of capture
Here are some lessons to take away:
- Sometimes you think it’s going to be a lot harder than it is to get everything green. I was expecting a lot of red when I added the restriction that the move target couldn’t contain a piece, but none happened. Better to know quickly via experiment than spend a lot of time squinting at your code. It’s important to reason out why you were mistaken, but getting verification first and working backward will generally save time.
- You can get a little too clever with what you’re doing. I was trying to get to green by adding sort of a silly hard-coding, and it came back to bite me. Such is the nuance of “do the simplest thing to go green.” No matter how many times you do this, there will always be times you fumble or do dumb things.
- I got a bit sidetracked trying to figure out how to push that base class constructor into the children, but came up empty. I’m not going to lie — if I weren’t recording for an audience, I would probably have scoured the internet for a way to do that. If you’re not in a time crunch or you’re willing to do that on your own dime, these can be great learning exercises.
- As I work with these Linq expressions, you’ll note that I’m not especially concerned about whether I’m iterating over a collection too many times or performance in general. Not that it’s directly applicable, per se, but I’ve always loved this post from Jeff Atwood. There are only two things that make me care about performance in the slightest: unhappy customers and unhappy me with bogged down unit tests. Until one of those things starts happening, I consider performance orders of magnitude less important than readability and just about any other concern you can think of. I can easily make readable code faster, if necessary. It’s really hard to make a pile of unreadable crap written “for performance purposes” into something that makes sense.
- We’re getting fairly close to a full implementation of non-specialty moves (en passant, last row replacement, castling), so perhaps its time to take a real chess game and model the actual, possible moves to create an acceptance test suite. Stay tuned.