ChessTDD 52: The Simple Beauty of Refactoring

In this episode, I decided to be content with the simple beauty of a refactoring.  I’m on the road and quite busy, including some presentations and a lot of driving around to various client sites, so it’s already a tiring week.  Add to that the fact that my car stereo is (was) apparently a hot commodity on the black market, triggering a thief to target my car in the Marriott parking lot while leaving every other car alone, and it’s been a pretty draining week.  So to sit down and code was nice.  But to sit down and clean up/delete code was sublime.

It’s always a win when you can do some cleaning, and so I decided to cap an episode early with nothing but that activity.

What I accomplish in this clip:

• Refactored GetCastlingMovesFor to be cleaner and more succinct.
• Laid a solid foundation for implementing castling for black pieces.

Here are some lessons to take away:

• Trust me — you’re never going to look back later and think, “if only I hadn’t spend those 15 minutes cleaning up this method!”  Take the time.  Clean the method.  You are definitely not going to regret doing so.
• Avoid “magic” values whenever possible.  Ask yourself if someone reading through your code would say “what on Earth does 7 mean here?”  Take literals and given them meaningful names as constants to be clear on their significance.
• Code is a lot easier to reason about when it is declarative, rather than imperative.  Whenever possible, write code that expresses “what” and not the details of “how.”
• It’s okay to give something a temporary nonsense name if you’re in the midst of refactoring and think you might not be done conceiving of what it’s supposed to do.  Just make sure you come back and give it a good name.  Don’t forget!

ChessTDD 51: Getting Castling under Control

Editorial Note:  These videos appear on my Youtube channel, but I’m starting to do a lot of other things there as well, including an upcoming series that I’m going to start uploading soon.  If you like the series, it’s probably worth subscribing to the channel.  You can subscribe by going to this link and clicking “Subscribe.”  

After flailing around a bit in the last episode, this one was a little more fruitful.  Castling is now somewhat more under control, and it seems like things are progressing along a good path.

What I accomplish in this clip:

• Added more robustness in the non happy path scenarios around the new CastlingStatusChecker.
• Got negative cases working for king and rooks having moved on the white side.

Here are some lessons to take away:

• Don’t get married to implementations.  Keep things light so that you can modify your approach as it makes sense.
• When it comes to collaborators in a class, reason about your preconditions on those collaborators (e.g. they can’t be null).  Check for problems in the constructor so that you can fail more closely to the problem than if you limped along and failed only when someone subsequently called a dependent method.
• As has been mentioned a lot in the past, make sure that you take appropriate time to pick good names for things.
• Experiment with your methods, trying on different local assignments and such, to get your code as readable as possible.  Hard to know what you’ll find readable until you actually see it.

Chess TDD 50: Back to the Green Field (Kinda)

Editorial Note:  These videos appear on my Youtube channel, but I’m starting to do a lot of other things there as well, including an upcoming series that I’m going to start uploading soon.  If you like the series, it’s probably worth subscribing to the channel.  You can subscribe by going to this link and clicking “Subscribe.”  

This time around, I actually get to do a bit of green field development again.  That sounds like a weird distinction to make, but I’d been so involved in modifying the existing pieces and the board class that biting the bullet and creating a class to handle castling was a huge relief.  I had fun this episode — so much so that I already coded 51.

What I accomplish in this clip:

• Created a class to evaluate boards for castling opportunities.
• Started the castling implementation in earnest.
• Proved to be really bad at telling X and Y coordinates apart.

Here are some lessons to take away:

• As with assemblies and namespaces, having dependency cycles with classes is a bad idea.  If class X knows about Y and Y knows about X, these should probably be the same class.
• When testing additional scenarios is a huge chore and you’re frequently having to worry about breaking lots of other tests, it may be an indicator that you’re cooking up an iceberg class.  I noticed this in the form of pain I felt when doing things to the Board class and the comparable joy I felt in this relatively green field work, today.
• Tradeoffs are everywhere in your software development process.  Refactoring while red is a risk, which I did without thinking to rename a method parameter.  But not renaming the parameter is also a subtle risk because I might forget to do it while getting to green and leave a sub-optimal name in there, possibly causing a future developer to make a mistake.  This is not to excuse my own mistake, but rather to point out that there tend not really to be “right” and “wrong” as often as we think.
• It’s really easy to make dumb mistakes and we all do and will.  TDD as an approach is so helpful because it mitigates the dumb mistakes by shortening the feedback loop between when you make them and when you notice them.

Chess TDD 49: Castling is Hard

In this episode, I start to discover that castling is hard.  There’s unusual movement, the fact that 2 pieces move simultaneously, and the fact that you have to keep track of a lot of status.  People have even commented on this being a particularly hard facet of the game.  Oh well, c’est la vie.  I think I came up with an idea for a helpful strategy during the course of this episode, even though this episode itself wasn’t wholly productive.

One thing to note if you’ve been following this series is that I’ve switched to Visual Studio 2015.  I brough CodeRush, NDepend, and NCrunch along for the ride, not to mention some of my preferred VS plugins.

What I accomplish in this clip:

• Fixed castling implementation to the long side of the board.
• Got a little more organized in Trello.
• Started on implementation of not allowing castling when pieces have moved.

Here are some lessons to take away:

• When you need to correct a mistake or bug, make sure you start with a red test that exposes the mistake.
• It’s okay to have a situation where making a test you’ve altered green makes others red.  If those tests are now wrong or out of date, this gives you basically a checklist of the tests you need to fix.
• If you consider yourself advanced enough to skip a step, it’s still always possible that you’re making a mistake.  TDD is all about micro-hypotheses and verification of your understanding of the code.  If you find yourself being wrong, slow down and get back to basics.
• No matter how long you’ve been at this, you’ll still make mistakes, especially if you get a little fast and loose.
• If you write a test to confirm your understanding of behavior in a certain context, I recommend leaving it in.  If you were wondering about that behavior, chances are someone else will, later, as well.

Chess TDD 48: Getting Started with Castling

Back in the saddle and making these regularly once again.  In this episode, I start implementing castling.  This proves to be something of a challenge because I’d gotten into such a routine of adding acceptance tests for the Pawn feature and changing mainly the Board class.  Here I’m in a different set of acceptance tests and changing a different set of production code, so it took a bit to get my bearings.  Castling, like en passant, is also a non-trivial edge case that deviates a fair bit from standard piece movement.

What I accomplish in this clip:

• Implemented castling to the short side of the board.
• Implemented castling to the far side of the board (though I think I got the move wrong).

Here are some lessons to take away:

• It’s a big help if you keep a nice, large surface area of testable code in your code base.  This lets you dig in with the granularity of your choosing for writing tests.
• You need to carve out time to keep your code clean and do boy scout refactorings.  If anyone is telling you not to do this, that’s a serious organization/group smell.  You need to keep the code reasonably clean to sustain the pace at which you deliver value.
• As you have a larger and increasingly complex code base, “do the simplest thing that will work” becomes an increasingly tall order.  With more tests that can go red, it gets harder and harder to do trivial things that satisfy all tests.
• It’s important to audit your tests continually to make sure they continue to add value.