Coding Dojo #10: Isola III
In our latest coding dojo we continued working on Isola with a focus on adding functionality following on from last week’s refactoring effort.
We used the Randori approach with four people participating for the whole session.
What We Learnt
- Our real aim for this session was to try and get the code into a state where we could reject an invalid move i.e. a move to a square that wasn't adjacent to the one the player was currently on. As we still had the whole board represented as a string this proved to be quite tricky but we eventually came up with an approach which calculated the difference between the last and current moves and was able to tell us whether or not it was valid. This didn't cover diagonal moves, however. We found it pretty difficult to drive this functionality due to the way the board was represented.
- What I've found surprising is how long we've been able to get away with having the board represented like this. Ideally we would have it represented in a structure that made it easy for us to make changes. This would require quite a big refactoring effort which we shied away from, I think due to the fact that we would be working without a green bar for quite a while during the refactoring. It wasn't obvious to me how we could refactor the code in small steps.
- Halvard pointed out that while we don't want to do Big Design Up Front, what we did in the first week of Isola was No Design Up Front which was equally harmful. Finding a happy medium i.e. Enough Design Up Front is necessary to avoid the problems we have run into here.
For next time