We're nearing the end of our second iteration on a new project. I started out by setting myself a few goals to explore. I'd like to write them down here, so I can come back in a few months to see what remains of them. You're welcome to comment on these goals.
Overall
- readable, intent revealing software
- DRY, YAGNI, BOYSCOUT et all...
Entities:
- IAggregate root has interface
- No ID (I'm not sure if I can pull this one off with NHibernate)
- No (public) setters except for things like name, description, ...
- State based tests
- Testdata: take a look at
NBuilderServices
- almost no logic
- infrastructure: queries, mapping, ...
- hosted in spring.net
- Behaviour based tests
Controllers
- no logic
- only view concerns
- choice of view to render
- navigation (redirect)
- forward call to service
- Behavior based tests
- hosted in spring.net
Repository
- only handles aggregate roots
- only the following methods: add/remove/query
Queries
- Separate query objects that get passed in the 'query' method of repository
- Preference in this order: LinqToNH, Criteria, HQL
- Integration tested
Security
- RhinoSecurity?
WCF
- Service hosting in Spring
Testing
- Heavy emphasis on readability
- Intent (test) Driven Development
- Fitnesse first (red), then unit test(R=>G=>R), integration test (R=>G=>R), Fitnesse green
Note to the one reader I have (Hi mom!): I accidently deleted this post, so this is a repost.
I’ve just started a new initiative in our company: a coding dojo.
I first saw this last week at the XP days, and I loved every minute of it. Emmanuel Gaillot introduced us to this idea with a simple challenge: compare poker hands. The implementation was written in Haskell from scratch, using TDD and Baby Steps. As Bob Martin mentioned: the beauty of this was that most of the attendees did not know Haskell, but they were able to follow what Emmanuel was doing, and make recommendations regarding the design. Most of us learned a little Haskell too.
I contacted a few colleagues to see who would be interested in this experiment, and 9 of us turned up. I brought enough beer for the group, and we got started. We first decided by dot-voting that the coding challenge should be the ‘classic’ bowling game kata. Each of us took turns behind the keyboard for a maximum of 5 minutes.
After the exercise, we held a retrospective. This is what came out of it:
What went well:
- Fun environment
- You have the right to fail. Tests will catch you, but no one will laugh at you.
- TDD with small steps
- Refactoring for readability
- Learned a few shortcuts in visual studio
What could have gone better:
- Let the driver and navigator do the work. The audience can comment, but if you want to argue, stand in line to code.
What would improve the coding dojo
- Try out new languages: java, ruby, groovy, haskell, F#, ook…
- Do this on a monthly basis
All in all this session was a success, as all participants will agree. Here’s the code we came up with. We do realize that this code isn’t perfect, but at least it works AND it’s readable.
using System;
namespace Dojo1
{
public class BowlingGame
{
private readonly int[] rolledPins = new int[21];
private int currentRoll;
public void Roll(int pins)
{
rolledPins[currentRoll] = pins;
currentRoll++;
}
public int GetScore()
{
var score = 0;
var rollNumber = 0;
for (var frame = 0; frame < 10; frame++)
{
if (IsStrike(rollNumber))
{
score += 10 + StrikeBonus(rollNumber);
rollNumber++;
}
else if (IsSpare(rollNumber))
{
score += 10 + SpareBonus(rollNumber);
rollNumber += 2;
}
else
{
score += FrameScore(rollNumber);
rollNumber += 2;
}
}
return score;
}
private int FrameScore(int rollNumber)
{
return rolledPins[rollNumber] + rolledPins[rollNumber + 1];
}
private int SpareBonus(int rollNumber)
{
return rolledPins[rollNumber + 2];
}
private bool IsSpare(int rollNumber)
{
return rolledPins[rollNumber] + rolledPins[rollNumber + 1] == 10;
}
private int StrikeBonus(int rollNumber)
{
return rolledPins[rollNumber + 1] + rolledPins[rollNumber + 2];
}
private bool IsStrike(int rollNumber)
{
return rolledPins[rollNumber] == 10;
}
}
}