Recovery strategies for legacy applications
I got a new assignment in which I redesigned some legacy COM applications in .Net WPF. If possible, I need to reuse functionality or existing code, however I suspect that this is limited.
I need to replicate existing functionality but need to be achieved using a modern and extensible architecture.
Does anyone have any general tips for approaching this type of project? Are there any good resources on this topic?
Are there any tried and tested methods or common pifalls?
source to share
I am currently doing almost this thing.
The most important advice I can give is to revise the system specification. Without new expectations of what you will deliver, you will stick to the standards of the old system. These standards can't be big, or you wouldn't be rewriting it.
Determine, from the people using the current system, what they are actually trying to accomplish and have built that, not a direct port. In the end, everyone involved will be better off.
Other than that, don't try to add features during this process. This opportunity will come after you have reconfigured the application. There is nothing worse at implementing a port than adopting a new requirement that conflicts with existing functionality.
source to share
The most important thing is automatic validation (aka / functional tests). See this question . How many tips would be simillar.
By that, I don't want to write tests for the new system, I mean write tests that go through the old system and will go through the new system. This will be the way you make sure you recreate the original functionality. I think that on a system that already exists, you could easily (albeit tediously) create functional specifications that can be done in BDD style .
source to share
I would say that a common trap is trying to fix what is not broken. Think about how you can reuse existing software without re-creating it. If it was a long time ago, it may be because it worked very well. You have a big challenge ahead of you to keep up with functionality without introducing new bugs.
Again, this could be due to the fact that your company has outgrown this outdated system. Think about why you are being asked to restructure this and what limitations the old material has that you need to address.
source to share
Michael Feathers: Working Effectively with Legacy Code contains a number of techniques for working and replacing legacy code. I found it quite readable; some of the methods (and many of the hacks) were new to me.
source to share
Keep track of your goals. Do you just want to replace COM funds? Are you also going to change the database implementations (from indexed to SQL for example?) Screens (from GUI to Web?) ...?
If it is a very small application, it could be completely rewritten by hand. If it's a modest size, you can modify the existing application (presumably to replace COM objects with another equivalent schema). If it is medium to large, you will hardly be able to rewrite or change it reliably in a reasonable time frame.
For such large-scale changes, you may want to consider automating the changes. A tool to implement such changes can be found here: DMS Software Reengineering Toolkit . Using DMS, for a client with 800K SLOC of C ++ code, we implemented most of the C ++ - C # transseterator, which replaced the COM interfaces with equivalent C # means (controlling the movement of the birdhouse about 3/4 of the way through the project generated interest in translator, despite its close completeness).
One thing to keep in mind when you do this: focus on modernizing your application without changing functionality. Often times, management cannot resist creep ("well, while we're there, we give the opportunity to change the application ..."), which is a road to disaster. Remember that all the changes that led to the current one took years.
source to share
Remember, when deploying a recently redesigned system, you will likely have to convert or migrate a whole bunch of data from the old to the new. Think about it as you go, because this job can get as big as your rewriting if you don't. Incorrect conversion, reliable or efficient, can doom you to a new system from day one, even if the feature is enabled.
source to share