The evolution of a Flex project
17.07.09Filed Under: Flex
One of the most challenging tasks when being architect on a large project is to keep some kind of track on what developers are doing while you are wasting away time in planning meetings and all other kinds of useless management activities. In the Flex echo system there are very few tools which help you track the code being produced and the quality of the code produced. Being a Java developer I am accustomed to have a set of tools which help me analyze code quality on a large scale enabling me to keep track of development without getting too deep into the details. There are some tools available for measuring code quality in Flex and Action Script, but they all seem immature and not really ready for actual use. Therefor I decided to abandon my quest for code quality and settling for keeping track of what is produced.
The tool
Equipped with the basic shell commands available in Linux I set out creating a simple shell script which works through the workspace directory of our CI server Hudson. The script runs each night and produce a report XML which gets aggregated using a PHP script to get all the statistics. On top I built a simple Flex dashboard which visualize the findings for the script.
The script counts the number of source files for MXML and ActionScript and also counts the number of code lines in each of them. During the work with this script an issue with build time surfaced, so we decided to add a tracking for that as well. The build time and SWF-file size parameters gets read from the Hudson status XML files.
The findings
Having run the script for a couple of months I have some data show how our application is growing and at what pace. The end of the graphs shows how Norwegian summer vacation effects the amount of code produced (number of developers is reduced with about 90%).
The most worrying graph right now is the number of code lines in our MXML files. Looking at the graph for code lines and number of files you will notice that we have a considerable larger amount of AS files than MXML files. However the number of code lines are not that far apart, which could lead to one of the following inclusion:
- MXML files are bloated and need to be trimmed down
- AS files are naturally smaller and there is no need to worry
Looking in detail at the code we’re closer to the first conclusion than the second and this is useful. Another interesting finding is that we’re not doing a good job of managing our assets as the file size just keeps growing. This told me that we needed to ensure that all developers understood the impact of embedding images in the application and that this is something which must be taken into considered when adding new images.
Anyway, I just found it interesting to see how the application will continue to evolve. We’re not to complete the project for another couple of years so it would be interesting to see what these graphs looks like in 2011. If you have made any similar efforts it would be interesting to hear how other projects evolve.
2 Responses to “The evolution of a Flex project”
Leave a Reply
Subscribe to comments feed (this is global, not just for this entry)
Looking at the graphs, I was thinking “uh oh, that looks like an awful lot of complex logic on the client side in all those ActionScript files”.
As long as the amount of functionality delivered with the code base grows, I also wouldn’t be too worried about the growth of the code base in terms of MXML. But the increase in growth of ActionScript would worry me.
Oh, and what happened with the number of AS files in June?
July 17th, 2009 at 11:22 amIn June I think there where some new teams added to the project. June was also the point where we started adding more advanced features to the application. Up until then it had been a fairly simple application, but in June that changed. This resulted in a whole lot more domain objects creeping into the application and if you look at the lines of code graph, it doesn’t spike as much as the one for number of files. There for the reason for the spike might be the introduction to a whole bunch of new AS domain objects which we previously didn’t have. I regret not having the same measuring tool setup for Java (or back end technology) as it might have a similar spike if my assumptions are correct.
July 17th, 2009 at 11:58 am