21 packages, 188 classes, 20,000 lines of code
Automatic unit testing , Automatic daily builds,
Does this sound like a Flash program to you? Because it is.
When we started building MindCanvas, we looked around for what the best practices were for developing rich web-based software. We didn’t find anyone else doing it, so we rolled our own best practices for Flash development together (see this article from last year). We refer to it internally as “java-style” flash development. It is shamelessly copied from the best practices in “traditional” (web-based / client-server) software development.
Besides copying standard practices from traditional software development, we also avoid doing anything that would seem weird to a Java developer. That means we never use the “timeline” that Flash designers love to use so much, and that we don’t have any layers in our initial Flash file. The only thing we use the Flash authoring tool for is
1)developing graphic elements (here the vector graphics capabilities of Flash are a major win)
Avoiding Flash-specific programming methods keeps our programming model as similar to “regular” programming as possible.
Doing “java-style” flash development, with an emphasis on inheritance, design patterns, package structures, and maintainable code, is really quite similar to developing in Java or any other object-oriented language. The benefits include highly maintainable software that new employees can easily learn their way around. The disadvantages include increased development time for the initial release, a temptation to geek out on design patterns instead of doing real work, and a risk of creating an over-architected, static system that is hard to change.
We believe that the first-generation web, where every user action required a trip back to the server, was sub-optimal. The pendulum is swinging back towards putting more and more logic on the client. And as that happens, the code that is supposed to run on the client side will get larger and larger (Note: this applies to AJAX as well as Flash). Whatever technology you’re using, there are some basic things that you need to do once a body of code gets beyond a certain size and complexity. Client-side code is now reaching that stage.
Design Patterns: Design patterns are stereotypical ways of solving engineering problems. Design patterns are language-agnostic, and so can be directly used in Flash Programming. For example, we use the “Model-View-Controller” design pattern throughout our code to separate the code that controls the application logic from the code the controls the display..
Packages: packages are important for two reasons.
1) They allow you to segregate your code into collections of files that are dedicated to specific purposes. This reduces the amount of code that an engineer has to read or think about when working on a particular problem.
Second, packages are a way of avoiding “name-space collisions”, where a common class name or function name (say “Controller”, or “validate()”) is used twice by two different engineers.
Automatic evaluation of code
One major advantage that strongly typed languages have over scripting languages is that they must go through a compilation process. While this adds overhead between development and deployment, it has the advantage of identifying programming errors at “compile-time” rather than “run-time”, when troubleshooting will be harder. We write our actionscript so that it is as strongly typed as possible, to facilitate catching as many errors as possible at complile-time.
Automatic deployment of code
It’s important to have a reproducible procedure for deploying your software to a server: otherwise, it’s hard to know (when you encounter a problem) whether the problem was caused by a deployment mistake or by a bug in the code. We build and deploy our code using customized ANT script, so that every step is embedded in code and can be reproduced by anyone.
What’s different about writing a large application in Flash, compared to Java?
The first observation I have is that we haven’t been able to get as much code re-use as we’d like. Good third-party libraries aren’t as available in ActionScript as they are in Java, so we aren’t able to “stand on the shoulders of giants”. But even within our own team we haven’t succeeded in reusing code as frequently as I would like. Of course, code reuse is often hard to achieve, even doing java development. I’m not able to put my finger on why this has happened, and whether it’s something specific to my team / project or something generic to ActionScript development.
Another observation is that compilation is really slow. This means developers HAVE to have the latest and greatest desktop machines, and that developing on a slower machine (like my laptop) is a pain.
One pleasing side-effect of the RIA architecture is how simple our back-end code has become. With display and business logic being mostly handled by the client-side, our java code is barely a thousand lines of code, responsible mostly for serving up xml from the database, and writing xml back into the database.
All in all, it’s been a reasonably positive experience. You can build reasonably-sized software using Flash, as long as you are as disciplined as you would be using other technologies.