I attended WEBDU the other week and had some thoughts after listening to one of the sessions – Geoff Bowers’ “taming the code”.
Amazingly over half the people in the audience weren’t using any form of version control. While we’ve been using version control for a few years now on our flash projects, It made me think about the development methodologies and processes that we have developed in the flash team at Massive over the last few years, specifically in relation to maintaining a common centralised code base.
The way i see it, there are two types of common code libraries – constant and evolving.
Constant code base
This comprises of functionality that rarely changes. Good examples of this are utility classes (e.g. trimming white space on a String or a generic XML parser). These classes are added to over time (in the case of utility classes as new conversions/formats are required), but the usage of existing methods remains the same across all projects – the returned format of a NumberUtil.toDollarsAndCents() method is always going to need to return a string with 2 decimal places.
Evolving code base
This is the common code base that evolves over time. At massive this is primarily the frameworks we use for our applications. While there is little change individually from project to project, over time our processes evolve and all the subtle improvements add up to a distinctly different framework. A project that is only 6-12 months old looks and behaves quite differently to a project started today.
Despite this, it is still necessary to version control the code base for our frameworks – because the alternative is to copy and paste core classes by hand every time we start a new project – yuck! At the same time we don’t want to have to maintain backwards compatibility in our common code base just in order to be able to recompile old projects.
Solution
Our solution to this problem has been to not version control the actual classes for our frameworks, but instead version control scripts that can automatically generate them. This way each project has its own version of the core classes that are fixed within that project, and every new project contains the most recent set of classes and structure.
There are heaps of benefits to this approach – not only do we not have to worry about breaking old projects – but we gain an extra level of standardisation across our projects no matter who initially creates them. Setting up a new project by hand can take hours and is often the most tedious part of the process. Automating this process saves time and heaps of monkey work.
Because we primarily use Eclipse for our actionscript development, we’ve been using Ant for all our build scripts (Eclipse has inbuilt support for it). Initially our scripts were responsible for creating a few folders, and some stub core classes. Over time we have extended this further to auto-generate project specific build scripts for both compiling a project and also creating specific class types on demand.
