views:

111

answers:

1

We have an internal Flex application which has been designed more through feature creep than by any kind of clear vision. It's basically a kind of CRM and reporting system which utilises quite a lot of Flex components (trees, graphs, custom components, datagrids - all sorts) and talks to a .NET webservice backend.

It was initially my first Flex project and has been written with the bodge, hope and repair kind of style you might expect from a prototype. However, it's now grown to the point where we'll be adding other (neophyte) developers, but it might not be impossible for one person (sigh, probably me) to rewrite the current snapshot in about a month. So, at this stage I'm thinking it might be a good idea to consider a new version implemented in the Mate framework.

I don't need advice on which framework to choose, what I would like is advice on how to go about refactoring the project. It seems like this will involve tearing everything down and pretty much starting again (which I'm not totally averse to), but does the framework have to be built in from the ground up? Are there any known and recommended methods of attacking this kind of problem?

+3  A: 

I did a similar thing a couple of months back. What I did was that I created a new package structure and moved all "ported" code there as I went along. I started with the overall view structure and moved my way towards the "branches". The new code referenced the old where needed, but no old code referenced the new. Having a new package structure helped in making it clear what had been ported and what had not, and it was also easy to see when I made progress.

Theo