I wouldn't quite say I've been a Flex "Hack" up until recently, but I definitely haven't had the same level of tooling and formality behind my Flex applications as I have in the ColdFusion realm.

After working with slippery beasts like the dynamic typing of ColdFusion and the unpredictability of HTML interfaces, Flex is such a wonderful development environment that I've often felt it unnecessary to use many of the tools and techniques I've relied on in HTML-focused ColdFusion development.

On my current project, however, I'm changing my ways. Here's a quick list (not a tutorial) of tools I'm using that are changing my world:

FlexUnit

On the server side, unit tests have saved me when it comes to developing ColdFusion-backed Flex applications. It's a lot easier to develop services against programmatic tests than it is to work through a Flex UI.

Until today, though, I'd never used FlexUnit. In the past half-hour, I've installed it, written tests against the four Cairngorm commands (we just started it yesterday!) in the application I'm working on, and I can now test the controller, model, and services tier of my application without clicking through a UI. It's good stuff, and I'd recommend downloading the tool and reading Darron Schall's tutorial.

FlexAnt

Why use Ant when you can compile via Flex Builder?

In my current situation, it allows us to set up daily builds of our application on a testing server.

In other situations, it'd allow you to automate builds of your application pointing to alternate resources (such as environment-specific services-config.xml files, etc).

Additionally, my current project is to be "brandable," allowing alternate UIs to be used while keeping a single code base of controller, model, and service tier code. We're accomplishing this by writing the application in a code-behind style (see next section), using Ant to compile against a Flex library projects for each "brand" containing view-tier assets.

By doing all of this via Ant, we can use a single build script to compile and deploy changes to all brands of the application simultaneously.

Code-Behind

Code-behind is a technique that separates UI code from UI component declaration. I'm still a bit on the fence about it.

On the positive side, code-behind allows me to write UI code that'll be common across all of our "brands," allowing the actual view implementation to change drastically without altering underlying functionality.

In other words, presentation-focused developers only worry about the MXML tags. I worry about handling their behavior and linking them together in a code-behind class.

It's not without its quirks - Binding is nearly broken, requiring me to manually bind in the code-behind, which could trip up presentation developers wanting to more with bindings (or require them to write AS code in their view, which somewhat defeats the point of code behind).

Additionally, I'm afraid of how much code some folks may cram into a code-behind, mistaking code-behind for a full separation of concerns / MVC style architecture. Especially on the AIR side of the fence, it wouldn't be surprising to see an ASP.NET-style mess of SQL queries being placed inside of UI-tier event handlers (creationComplete on ContactListCodeBehind.as fires an SQL query to list contacts - whoa, it sounded OK in theory!).

Conclusion

If you're looking to make a shift from occasionally writing Flex applications to making them a large part of your development life, I'd encourage you to explore all three of these techniques / technologies. They're fairly lightweight ways to make Flex development easier, more productive, and more professional!