As my last post was a little ‘Dear Diary’, I thought I’d make this one more ‘Cold Hard Coding’ with a bit of post-project analysis.
Doesn’t that sound thrilling, one-and-only reader? Oh you know it does. Please tell me it does. No seriously, please. Please stay.
Our first weekend challenge was very similar to our first project in that it involved storing objects (planes) in other objects (airports) and controlling their state (airborne) by sending messages between those objects (Land! Take off!).
For anyone with a glut of time on their hands, you can check out my code in all its gory glory on my GitHub. But I thought I’d also chat through some of the main takeaways we discussed as a cohort during review:
There are only two hard things in Computer Science: cache invalidation and naming things” – Phil Karlton
During our first day at Makers, our coach claimed that naming things (classes, methods, variables) was one of the most difficult things a programmer can do. It’s a bold statement. It’s also one which most likely depends on your ability to actually write code – for me, the decision to name the method for landing a plane ‘land’ comes more easily than, say, cache invalidation would right now.
But I get where he’s coming from. Naming things well ensures that your code can be picked up, used, and adapted by people other than you. It also means that YOU can pick up, use and adapt your own code when you’re returning to it after a couple of sleeps. Surprisingly, this is also useful.
Great names should also mean minimal commenting. If you need to add a comment to inform another developer what airport.land(plane) does, ask yourself whether insulting others’ intelligence brings you some kind of sick gratification. Because that really is the only reason.
As a result of their untested nature, comments are always in danger of becoming out of date – eliminate that danger through intelligent naming.
Removing randomness in tests
This is something we all struggled with over the weekend. We had a fully functional program, tried and tested, that could control the movement of planes. The next step was to introduce a Weather class that randomly simulated weather conditions. If the weather was stormy, planes were prevented from landing/taking off.
(Snippets of) my code looked like this:
And in a separate Weather class:
So far, so reasonable. The problem comes when you try to run your tests:
Now that Weather has been introduced, this test for simply landing a plane will pass only when there’s no storm a-brewin’ – a state which changes completely at random. Not great.
To get around this, we needed to allow certain conditions to be outlined before certain tests are ran:
This did the job for me – setting bad_weather to return false in order to remove the randomness. Later on, I overwrote this condition to test that raising the error also worked:
Unfortunately, I’ve since learned this isn’t exactly the most foolproof solution. In effect, I am stubbing the behaviour of an Airplane method and, since it’s the Airport class I’m testing, that is rather risky. Since submitting my solution, I’ve learnt that there are these very useful creatures called class doubles I’ll be using going forward to achieve the same result.
I smell some refactoring!
All in all, I found the weekend’s work really very fun. It was great getting stuck into a brief now we have a couple more skills in our arsenal. I’m sort of ashamed to say it, but as soon as it was over I kinda missed it. What was I gonna do with my Sunday afternoon now?
Relax? Watch some TV? Socialise? Shudder.
Yes, I do realise I am hella sad. You’re not supposed to enjoy work – that’s The Rule. Bemoan that things will never change, make no changes, rinse and repeat. God, I think I might be morphing into one of those terrible twenty-somethings that loves what they’re doing…
Ok, One Reader. I understand. You can go on and unsubscribe now.