Successive Refinement

Just as today was getting a bit hairy, I stopped and read a bit of Clean Code. I happened to be on the chapter for Succesive Refinement, which worked really well given the circumstance I was in. For me, I have a balance to try and achieve between getting it right first time and letting the code grow a bit until I can see where it needs to be refactored. I have probably gone past that stage with my TTT now.

My downfall was not solidifying where my class’s responsibilities stopped. I have a Game class that runs the game, sort of carries some game logic and manipulates the flow of display and players. This might actually be ok, but I’m not convinced I have it right. I feel like the Board class should be responsible for providing facts about its state, and the Game class (which knows the rules) should be interpreting those facts. However, maybe that balance isn’t so easy. For example my DumbComputer class was behaving in a very similar way, taking state from the board and interpreting it (via some manipulation). This lead to some feature envy, which is the greater evil in this case. The waters around my board and game classes are getting a bit murkier, and I want to try and find the dividing line soon.

Uku said to me that I shouldn’t be completing stories where I am not happy with the code, and that certainly seems like a sensible idea. I will take some more time next week to make sure I am happy with the code that I commit, and not just focus on getting the story done as quickly as possible.

I had a long IPM this afternoon where Uku reviewed most if not all of my code, it was a great process for me, the feedback was all really helpful. I am going to action his points this week, and maybe get some more technical blogs written during the process.