I am a little squeamish about it sometimes, but usually I don't have any problems just completely breaking something I am working on. Over the many years I have been doing this, I've gotten quite adept at putting all the pieces back together again.
The only problem is when it's something you've put off too damn long, like I did with this one. Here's the situation.
Capo's server backend uses Hibernate for its data persistence. However, these can't be passed to the Flex client, because they're usually not complete objects - serializing them as is just causes either breakage (db session problems) or WAY too much data sent.
Plus, the backend needs to have access to data that the clients will never see.
The solution to this is the DTO (Data Transfer Object) pattern - basically you mirror your Hibernate VO (Value Object) with a DTO, omitting the data you don't want to transfer to the client. You can even (as I have done) have Factories that construct the DTO dependent on who is asking for it (ie, omitting information that one player might not know about).
Once you've got this DTO assembled, you simply serialize it to the Flex client and due to the magic involved in BlazeDS, it fills in an instance of the DTOs mirror class in AS3 (which you've had to create, of course.) There's an additional complication if you use the Externalizable interface in Java (IExternalizable in Actionscript 3) like I do to customize your serialization, as you have to write the readExternal() and writeExternal() methods on both sides. FUN!
Now, the problem with this is when you get really crazy amounts of classes. At my last count, I have 76 or so. And until last week they were all manually created, and it was a horror show.
So, last week I finally bit the bullet and wrote a code generator. There's several out there already, but none of them did what I required.
So now, here's my process:
Now, after changes on the server side, Eclipse builds the DTOs automatically for both sides, leaving out regenerating the derived classes if they already exist (thus leaving your custom code alone.)
Of course, you can imagine the chaos this causes when after nearly 4 months of hardcore development you replace the base data classes. After about 3 days of mind-numbing bug fixing, I've got it down to almost 0 errors and now it's time to start finding the runtime bugs, instead of the just the compiler errors.
So, the takeaway: Do your tools first. I avoided doing this because I thought doing it manually would be manageable.. If I had spent the 3-4 days at the beginning instead of right now, it would have been way smoother.