This command line application (CLI) was the first programming project that I ever built (apart from some terrible first websites, but I’m not going to count these 😜). I built it using JavaScript as the language, Node.js as the runtime environment and MySQL as the database system to store information about player scores.

The CLI enables one or more players to track their scores as they complete a standard game of ten-pin bowling. Once the game is complete, the players are thanked and a table of high scores is displayed.

It’s surprising how much logic is involved in a simple game of bowling. Spares and strikes give you additional points meaning that your next one or two rolls respectively are essentially counted double. Not to mention the 10th and final frame where the normal rules seem to be tipped on their head - any spares or strikes in this frame score no bonus points but allow you to take an additional 3rd roll. This means that XXX or 9/X or XX3 in the final frame are completely legitimate scores.

As you can start to see, there are plenty of edge cases in bowling. So I started writing tests (using the Jest testing framework) as my logic got more and more complicated and I became scared to change my code out of fear of breaking something else.

I’m pleased that I did this and also that I experienced the usefulness of writing tests in tandem with building software. In my test files I wrote a lot of integration style tests (amongst others) where I was essentially asserting the string being outputted to standard out. This approach now strikes me as pretty brittle - if I change the format of this string, all my tests would fail 😭. Having learnt about the testing pyramid, if I re-wrote the software today, I would concentrate more on converting these to unit tests instead, perhaps using a table driven approach for all the different permutations to test. Consequently, I would be testing smaller pieces of code and wouldn’t be reliant on how the output string is formatted.

There were quite a few dodgy decisions I implemented simply because I didn’t know any better (it was my first programming project after all). For example, I only connected to the database once a game had been completed. That strikes me as a bit bizarre - I would instead create a single connection on app initialisation and then pass this around (or require() the file, as is the case with JavaScript). If I was feeling really fancy I could create a connection pool, though this optimisation seems a bit overkill for an app with only two database queries per game.

However what probably takes the biscuit in dodgy decisions would be hard-coding database credentials. But then not only that but committing them to source control too 😱. Yikes, definitely something I would never do today. But I suppose that’s the beauty of improving and getting better - you make mistakes but can also rationalise as to why it’s a bad idea too.

To summarise, I really happy with how the CLI turned out and I enjoyed implementing all the logic involved in a game of bowling. I’m glad I was able to experience the utility of tests so early on in my career as I’ve definitely worked on project teams where this hasn’t been a priority. Looking back at the code that I wrote years ago has been an interesting experience too - this is something I never normally do and has been a fun thought experiment thinking about how I would rewrite the software with the knowledge I have now.

In need of a back-end engineer for your project? Get in touch to hire me for contract work 💯