This is a problem I have encountered several times in the past, inheriting reasonably large, poorly documented code bases. It can be an interesting personal challenge, deciphering someone else's code, but not when you are working to a timescale.
I became so frustrated that I decided it was time to try and do something about it.
As a result, we (myself and a couple of other developers) have developed a new software tool which aims to cut through legacy code, to visualise it in an abstract way, and to allow you to build a picture of what its doing quickly and efficiently.
In simple terms our tool (named 'Code Rocket') is a detailed design documentation tool - kind of like doxygen, but taking documentation a step further.
We use it to prevent the code from becoming a legacy nightmare in the first place (by ensuring it is structured and documented to a high standard but with limited overheads for software developers during development) and to reverse engineer the meaning of any existing legacy code to guide us through an understanding of it. There are many other side benefits as it turns out relating to project management, review, communication, but the main thing is that I now feel a little more comfortable when presented with a batch of legacy code to investigate. I also agree with the recommendations of building in unit tests.
Slashdot Mirror
This is a problem I have encountered several times in the past, inheriting reasonably large, poorly documented code bases. It can be an interesting personal challenge, deciphering someone else's code, but not when you are working to a timescale.
I became so frustrated that I decided it was time to try and do something about it.
As a result, we (myself and a couple of other developers) have developed a new software tool which aims to cut through legacy code, to visualise it in an abstract way, and to allow you to build a picture of what its doing quickly and efficiently.
In simple terms our tool (named 'Code Rocket') is a detailed design documentation tool - kind of like doxygen, but taking documentation a step further.
We use it to prevent the code from becoming a legacy nightmare in the first place (by ensuring it is structured and documented to a high standard but with limited overheads for software developers during development) and to reverse engineer the meaning of any existing legacy code to guide us through an understanding of it. There are many other side benefits as it turns out relating to project management, review, communication, but the main thing is that I now feel a little more comfortable when presented with a batch of legacy code to investigate. I also agree with the recommendations of building in unit tests.
If anyone is interested in checking out our tool, you'll find it at the following web site: http://www.rapidqualitysystems.com/