Recently, I've been working on what is probably the "Ultimate" legacy/Brownfield application. It's a VERY important application for our business, or WAS, but the users are starting to find other ways to do their job. The problem is that the application in question is VERY hard to maintain, and management does not want to risk making any "non critical" changes. It's the classic "Big Ball of Mud" design.
Now no matter HOW many time's I've read Michael Feather's Working Effectively with Legacy Code, I can can never quite figure out how to make it work in this case. There are almost no seams to exploit. We have numerious routines that have a Maintenance Complexity in the 2000 to 3000 range. Of course these routines have no REASON to be that complex, it's just that previous programmers had a tendency to lump all sorts of things together that had nothing in common except that they needed to execute at the same time.
DRY? They never heard of it
The classes are just mirrors of database tables, and if a calculation needs to be done on a class or collection, the routine is usually inline in a form event, with "other" code mixed in.
I do find RefactorPro! to be a very useful tool, but even with automated tools, I have to take huge risks, just to get the code to the point I can start putting test harnesses on it.
Anyone else have to maintain a probram like this? The goal here is to get the application maintainable enough that I can start to add features to retain/regain our internal user base
No comments:
Post a Comment