CODEWITHSUNDEEP
architecturecomlegacylegacy-code
Steve
Steve

Reputation: 2093

Stategies for Rebuilding Legacy Applications

I have a new assignment coming up shortly where I have re-architect some legacy COM applications in .Net WPF. If possible I need to re-use functionality or existiing code however I suspect the scope for this is limited.

I need to replicate existing functionality but need to achieve it using a modern and extensible architecture.

Does anyone have any general advice for approaching a project of this type? Are there any good resources on this subject?

Are there any tried and tested techniques or common pifalls?

Upvotes: 1

Views: 812

Answers (6)

Ira Baxter
Ira Baxter

Reputation: 95392

Consider your goals carefully. Are you just interested in replacing the COM foundations? Are you also going to change data base implementations (e.g, from indexed to SQL?) Screens (from GUI to Web?) ...?

If this is a very small application, it might be possible to rewrite it by hand completely. If it is modest size, you might be able to modify the existing application (presumably to replace the COM facilities with some other equivalent scheme). If this is medium to large, you will not practically be able to rewrite or modify it reliably within a reasonable time frame.

For such large scale changes, you may want to consider automating the changes. A tool for implementing such changes can be found here: DMS Software Reengineering Toolkit. Using DMS, for a customer with 800K SLOC of C++ code, we implemented most of a C++ to C# translator that replaced the COM interfaces with equivalent C# facilities (a birdcage management shuffle about 3/4 of the way through the project killed interest in the translator in spite of its near completeness).

One thing to consider while you do this: keep focus on modernizing the application without changing the functionality. Often management can't resist scope creep ( "well, while we're in there, lets change the applicaiton to do ...") which is the road to disaster. Remember, making all the changes that lead to the current one took years.

Upvotes: 3

Bryan Watts
Bryan Watts

Reputation: 45465

I am currently doing almost this exact thing.

The most important advice I can give is to re-spec the system. Without a fresh set of expectations for what you will deliver, you will be held to the standards of the old system. Those standards can't be great, or else you wouldn't be rewriting it.

Determine, from the people using the current system, what they are actually trying to accomplish, and built that, rather than a straight port. Everyone involved will be better off in the long run.

Short of that, don't try to add features during this process. That opportunity will come after you have re-architected the application. There is nothing worse while doing a port than taking on a new requirement which contradicts existing functionality.

Upvotes: 2

mfx
mfx

Reputation: 7398

Michael Feathers: Working effectively with legacy code presents a number of techniques to work with, and replace, legacy code. I found it quite readable; some of the methods (and many of the hacks) were new to me.

Upvotes: 3

Preet Sangha
Preet Sangha

Reputation: 65516

The most important thing will be automated verification (aka unit/functional tests). Please see this question. As a lot of the advice will be simillar.

By this I don't mean writing tests for the new system, I mean writing tests that pass on the old system and will carry through the new system. This will be how you will verify that you've recreated the original functionality. I think in a system that already exists you could quite easily (though tediously) create functional specs that could be executed in the BDD style.

Upvotes: 4

Stuart Helwig
Stuart Helwig

Reputation: 9454

Remember that, as you deploy the newly re-architected system you are most likely going to have to convert or port a whole heap of data from the old, to the new. Consider this as you go because that job alone could become as big as your rewrite if you don't. Not converting well, reliably or efficiently could doom you new system from day 1, even if the functionality is spot on.

Upvotes: 2

tchen
tchen

Reputation: 2242

I'd say a common pitfall is trying to fix things that are not broken. Think about how you can re-use the existing software w/o re-inventing it. If it's been around for a long time, it may be because it worked really well. You will have a big task ahead of you to match the functionality w/o introducing new bugs.

Then again, it may be because your company outgrew this legacy system. Think about why you are asked to re-architect this and what limitations the old stuff had that you need to solve.

Upvotes: 3

Related Questions