At university, we mostly work on programming solutions to small given scenarios which, if you do it right, just works and then you move on to the next task. Working solutions, however, aren’t necessarily optimal as they can be written in a way that is not very friendly to future development and scalability. This is one of the more important differences I’ve found between the university and industry experiences so far and I’ve outlined a few useful things that may take a bit of extra thought initially, but will save time in the future.
fulfilling your testiny
Initially the idea of writing tests first seemed a bit strange to me as how can you test what you don’t have? After trying it out it started to make a lot more sense as it gives you a clear goal and actually ensures your code is properly testable. It is not uncommon to see methods performing multiple operations which can make unit testing difficult and usually ends up with certain parts being tested multiple times. Writing tests first gives you a clear view of the separate working parts of your code which, I found, also helps when organising your project structure. Once all your tests pass, you should most likely be finished which is a much better feeling than getting a working solution and then realising that although it’s doing it’s job, it is awkward to write tests for. This usually leads to time spent refactoring or some poor quality tests which could have been avoided by using a development style that is more focused.
A recent project required me to build a URI for an API request so I put a method at the end of the class that returned a built URI I needed. Great, that works! A bit later on I discover I need to build some others that didn’t quite follow the same format which left a mess of URI building at the end of my class. Oops. Extracting these was quite time consuming as they relied on fields that were in the original class. Planning for scalability and creating a new class containing that one original method would have meant all the information would have been in the right place to simply implement the others. It may have taken slightly longer initially, but overall it would have saved time and being able to identify situations like these before they occur is a very useful skill to have.
git commit -m “I did the thing”
At university, working on long group projects is quite disproportionate to the number of short individual assignments which meant the notes I was used to making were only for me within the context I had at the time. It didn’t take long to receive some helpful advice regarding my commit messages on git because of this bad habit I had developed. These messages are displayed for your changes to a remote repository and without a meaningful one, others that work on the project later may not fully understand the intentions of your modifications. It is easy to see what has been changed, but it is hard to see why when you lack the context the author had at the time. It’s also fully possible that the author of the code you are confused by is yourself! Taking an extra minute or two to be clear and concise will save the reader the mental effort to try and understand what you were trying to achieve. This resource was very helpful for my understanding and breaking out of this habit and I highly recommend a read.
If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.