Reverse Engineering a large, pretty complicated and poorly commented vb program?

WarrenBuffet

Registered User
Messages
173
Hi,

I have been tasked with understanding and updating a large, pretty complicated and poorly commented vb program (essentially i will have to reverse engineer it for myself before updating).

Does anyone have any techniques on how to do this? I understand i will have to get down and dirty with the syntax of the code itself but i was wondering if there is a tried and trusted methodology to help make this initially daunting task easier?

BTW I am not in the least bit familiar with the program at this point and help from those in the know will be minimal I reckon.

Thanks,
WB
 
Re: Reverse Engineering a Large Program

Run the progam, see what it does. Then put debugs in the code where you want to make changes and see what it does line by line. BTW you dont say what version of VB it is or the sort of changes you want to make. For example .NET has the ability to create class diagrams from the code, I don't know how much help these would be except that the might look prity if you were to cover a wall this them :)
 
A lot of the automated tools for such as mentioned by Towger are pretty poor at generating correct and meaningful results, and most depend on an object-based model having been applied in Development - i.e. something strictly not enforced by VB.

If you're objective is to update the code, then Towger's suggestion of debug-line-by-line to gain understanding is probably the pragmatic approach. That would be the quickest way of zero-ing in on where updates need to be made

If the objective is to create high level documents or specification of the code as a whole, then a line-by-line understanding may be necessary. ( Tip : Delegate to a Graduate :))

Look on the bright side, though, at least you've got the source code!
 
Look on the bright side, though, at least you've got the source code!

But does it compile? And does it compile to the current version of the program being used? That 3rd party products were used, can you still get them?
 
How large is the system? Is understanding it a realistic proposition in the time available? Is your real goal to update it correctly, without breaking existing functionality?

I'd start by getting regression tests in place, so that when you do make changes you can have some confidence that you haven't broken too much. Take some typical "good" (and "bad" inputs), and record the output from the existing system. Automated tests are probably best if possible, but tests don't have to be automated to be useful.

Can you break up the changes into small deliverables and put these into production as you go? This will help identify unintended side effects as you introduce them. Ring-fence the new code from the old as much as possible and you should gradually start to tidy things up over time.

And does it compile to the current version of the program being used?

If you're really lucky there'll be multiple different versions in production, none of which match the source code!
 
Sorry, wrong description. I have the source and I want to document clearly how it works......i really thought there would be a standard way of doing this.
 
Sorry, wrong description. I have the source and I want to document clearly how it works......i really thought there would be a standard way of doing this.

I get junk mails from a place in India which have a good hourly rate, well compared to here...

There are different standards/methodologies for documenting the code, but at the end of the day would really require eyeballing the code.
 
I am not afraid of getting stuck into the code. I just want a good method of how to do it which will ensure I don't become google eyed looking at it and also help break the project into smaller, measurable tasks.

To be honest I am thinking now of just concentrating myself on updating the code as required but drafting up a scope of works for a graduate / summer student / external consultant to really document how the thing actually works. In this scope i would need to break the project into small tasks with deliverables etc.
 
I get the impression you haven't done much coding before, because stepping through code is pretty much routine. Its broken down into modules, functions etc. If you can't talk to the original programmer, you should be able to talk to an end user who can tell you what it does. If the code makes no sense, its often quicker to rewrite an application than untangle someone elses mess. Especially if the original coder went to the trouble to confusticate the code to prevent others from reading it easily.

Break it down into Need to do, Nice to Do, Never Do. Don't fix what isn't broken.
 
Back
Top