Makers Academy Day 15
At the end of week 2 we had covered off an impressive list of concepts and skills related to TDD and BDD. The weekend challenge gave us an opportunity to implement these ideas in practice. The aim of this post is to reflect on this weekend challenge and constructively explore how I can improve my code.
To kick this off I’ve included a whiteboard diagram that maps out a good approach for tackling a class extraction exercise from our second week Oystercard project.
In this exercise we were taken down a dark path of classes that needed to be refactored and extracted into new classes because of some bad design, which led to one class having too much responsibility. What I found during my weekend challenge was that whilst the project I submitted fulfilled the criteria of the user stories, I had unwittingly done a similar thing.
Takeaway challenge — part 1
In the Takeaway challenge we were building a number of user stories which related to creating a takeaway service. During the previous weekends’ challenge I found myself scrupulously drawing domain models for each user story. This had an effect of delaying coding and also feeling constrained to stick to the domain model plan, I had taken an ‘Inside out’ approach which started with modelling and building unit tests. This would have been more valid if I had a lot of knowledge about the topic, but I didn’t so reflecting on that for this Takeaway challenge I took more of a ‘Outside in’ approach. I didn’t model anything upfront, instead I used pry to do some spiking. The benefit was that I immediately started building throw away objects which helped me think through the user requirements in code. I was aiming for, to paraphrase Kent Beck, my program to be the expression of requirements in code.
This was a good intention, but it went too far the other way. I ended up creating no domain model after the spiking, and went straight to the unit tests and the writing the code. I realise that I need to have an amendable domain model that can be tweaked based on my spikes and unit tests. I think this early omission of having thought deeply about the design requirements for the program as a whole, led to creating a takeaway class that carried out many behaviours that were outside of its remit. You can see a snapshot of the code in the class here:
Once I started going down this path, I stopped focusing on the mini design questions at each step and instead focused too much on fulfilling the user stories. This meant that I rapidly built a class which I knew quite early on needed/should have been extracted out into other classes. I had already created some other classes such as ‘menu’ and ‘display’, but they didn’t do much. Instead Takeaway continued to have pretty much all responsibility, and this made the prospect of carrying out class extraction at the end of the challenge a large task.
In summary, I should have better designed the program to make sure that I didn’t have one monolithic class. I also should have given myself the time to make sure I made design decisions each step on the way, instead of wanting to push on and build the features. In taking that approach I created an enormous technical debt on a greenfield project and ultimately made my life a lot harder.
In the next post I’ll detail how I refactored out this class and the learnings I made.
