Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Get the latest Education e-news
  • Crossing Ships

    - Alan Abram

    Working in a team on a code base is pretty challenging sometimes. When you work at university it is not very common for people to be working on the same application at once. The application might be passed around a group of people who update small segments of the application and then pass it on. Obviously this isn't a viable option in a business. That's where source control comes in.

    The entire project, along with all its assets were stored on a server. Source control software allows everyone in the development team to have access to the latest versions of the code and data whenever they require it, as well as allowing accessing to the history of these files and keeping a safe up-to-date copy of them. Users ‘check out’ the files they need to edit.

     Once finished, these changes are checked  back in to the server, becoming the current version and available to the rest of the development team. This could lead to two people opening and editing the same files and potentially editing the same lines of code., Luckily there are tools to check and resolve code conflicts such as these although they still aren’t perfect, and require you to manually check over the code to ensure its correctness before checking your files back into the server.

    Breaking the builds can be very costly for a company, for example if 10 people excluding yourself were working on the project at the time you broke the build, this could potentially stop them all from working on their bits of code. If it takes you an hour to fix the build for everyone then you have cost the company the amount which those programmers would have been paid during that time.

    As a someone new to the industry before any of my code was checked into the server, it was "code-reviewed", which basically meant that we would go through the code I had written and make sure everything looked fine and I wasn't doing something totally stupid to make it work.

    At first this was quite intimidating, having someone look over everything you had written and then telling you that something needed to be changed, but over the course of my employment I found that the code reviews were very valuable, as whenever something needed to be changed I was always given an explanation as to why it needed to be, and why it was not necessarily wrong but not appropriate for the context in which it was written.

    For example, when writing a program for university, you don't care about the amount of memory you application is using, most people have PC's with 1Gb or more worth of RAM, and that pretty much makes it difficult to run out of memory when working on the PC. Generally you don't care about memory fragmentation as that is all handled by your operating system. But when working on multiple platforms which have fixed amounts of RAM and different processing speeds, all these things become major concerns.


comments powered by Disqus