Flex Pitfalls
I am frequently asked to assist development teams with assessing their architectures, implementations, and deployment processes. In fact, whenever I start working with a development team,I have a mental list of issues that I ALWAYs use during the course of performing code reviews and recommendations.
While my "list" may be different for different technologies (Coldfusion, Java, Flex, Flash) and for client-side and server-side development, I thought I would outline most of the issues that I use when I am involved with client-side Flex technologies.
These issues - enumerated below - issues are categorized as "Pitfalss of Flex".
- General Issues -
Are coding standards defined and consistent within the implementations.
- e.g. are "reverse-url" package names used
- e.g. are camel-case (upper and lower) used appropriately
Are naming conventions understandable, maintainable, and consistent
What design patterns are used.
- Application Issues -
Are Flash assets (swfs, movieclips) used
How is embedded assets implemented
Are CSS used and consistent
Are Modules used to dynamically load functionality
How are effects utilizied
Are view states & transitions used
Is <mx:Script source="xxx" /> used
Does the application use custom events for controller interactions
- Controller Issues -
Is the code structured in a MVC pattern
Is Cairngorm used or a "home-grown" version
Are dataservices totally hidden for the model & views
Is FDS used (RemoteObject, Publish/Subscribe, DataSynch)
Is E4X used
- Model Issues -
Are value objects used
Are E4X models translated to ValueObjects
Is remote data [marshalling] deserialized as Objects or ValueObjects
Is [Bindable] used appropriately
Is data-sharing mandatory or only as needed
- e.g. views that maintain local data should not store that data in global repositories
- View Issues -
Do parent views cascade data to nested views
- e.g. Child views should almost never bind to global data (except for lookups)
Are the views decoupled properly
- e.g. use public properties & custom events for coupling
Are the views "black-boxed"
- sources of incoming data are unknown
- targets for outgoing events are unknown
- logic for specific view is localized
- are MetaData tags used appropriately
- are changeEvents announced properly
- are implicit getters & setters used properly
Does the application use custom events for view interactions
Do the views use custom events
Please note the above issues do not address the development considerations of "change management" (aka version control), build strategies and scripts, automated integration and automated testing, or deployment processes.
All together, when a development team addresses these considerations - even in a rudimentary fashion, then the deployed applications can be delivered with high-levels of confidence as applications that are robust, maintainable, extendable, and reusable.