What are some practical ways to resolve legacy code in an n-tier architecture where all of the code is written in self-referencing web services? So far, much of the code is undocumented, uses old VB6 conventions, and there are very long procedures. What's the best way to approach, let's say, a change of business rules for such a large project without having reliable documentation?

I have limited access to the original developer of the code. How can I better document the process and complete my assignments, knowing that the code is changing daily and there are several dependencies for each method, there may be xml files, sql queries, and other unconventional resources being accessed.

Much help appreciated.

i guess that you probably dont have all the time in the world to make drastic changes - you said that you makes changes daily?

when i had to do this, i made the time tho and re-wrote everything in .net

the only real way to do that with a legacy app without the original developer (and even if you had him probably wouldnt help much since he originally did it this way to begin with) is to document it everytime you have to change something.

suggest to your company setting up 'policies' or 'guidinlines' for new code
post them in the office. make the policies like document code efficiently, define all variables, break long procedures into smaller onces, dont repeat yourself. then do code reviews (if time allows) to make sure everyone is following the policies. it will save time in the long wrong - we are trying to implement it where i work.

good luck

This article has been dead for over six months. Start a new discussion instead.