Design Decisions

I was practising a Kata I haven't done in a while because I wanted to add a recording to the new Page I created dedicated to TDD Katas. The Kata in question was the Roman Numerals Kata (From Roman to Arabic).

After doing the Kata I ended up with this implementation:



This is fine, the solution worked but I just didn't like that those two nested loops seemed a bit of a lot of complexity. Probably not the best solution from the point of view of performance. I wanted to try something else. So I deleted that code and without deleting the tests I wrote this:



To me this seemed a bit better and probably faster. Optimisations are something that we should always postpone. Remember the saying?

Make it run, then make it nice, then make it fast.

Early optimisations can lead to unwanted over-engineering and some other problems. TDD teaches us that we need to grow our code gradually. But then how can we just refactor to something completely different than what we just got?

Once we have written all our tests and we are happy with our refactoring, the tests will act as our documentation, so even if we were to delete all the code and just leave the tests, we could recreate the code. So that is what I did initially to create that second implementation.

After observing the new implementation and compare it to the previous one, I decided to TDD to see if I could get to the code in the second implementation. I discovered that at the point where I was doing the refactoring after making the test for number 6 pass, here was the place where I could make a design decision and choose not to extract an enum and instead try something else.

This time the Kata has once more proven that TDD is not just capable of making safer code but also drive the design even when we are looking for a faster solution than the one we have.


Here the video for that Kata: