A clash of styles
I have recently been asked to merge two seperate vb 6 applications into one. One of them is a well written, well designed piece of software that uses classes, collections, is well documented, coded etc, in short a piece of work that was clearly written by a pro. The other is a ball of mud that has grown out of excel macros and ended up as a vb6 application. Both use the same oracle database and there are clear and obvious advantages in merging the two. The problem is I just want to rip the bad one to pieces and start again, adopting the development style of the other. the reallity is I could just cut the bad one as a dll and include it into the merged application (slight exageration but you get my point) - Oh the pain, it's doing my head in.
You jumped straight to Ch 10, didn't you?
Go the DLL route first. Get the merged functionality working and then as you find "issues" in the poor quality code base refactor or rewrite as required.
Len Holgate (www.lenholgate.com)
Take the application as your starting point and slowly work the features of the ball of mud into it. As you do so, pick clean the code and sort out the problems.
Agreed, being able to take these two applications and merge them so that they work in a very short amount of time is "A GOOD THING". But make a note at the time of release that you are going to spend some time refactoring and cleaning up the code so it can be maintained in the future. If you release a working version fast enough you shouldn't receive any flack about this request.
As Len says, encase the ball of mud in a concrete enclosure (e.g. separate DLL) but with new clean interfaces that for now tie into the mud. Then one-by-one you can rewrite the interface methods as time permits to point to new code, until everything is new and you can throw out the mud.
I agree with Len and Jack. First, make it work. Then make it right.
Great Comments, and good advice, I think I'll do just that.
Fog Creek Home