How to reverse engineer undocumented legacy application?

Question

Once I was assigned to a project which was about adding couple new features to the existing Java based web application. Because it was a matter of just couple simple features there was no chance for rewrite.

Unfortunately, the code base came from a client without any documentation and the code itself wasn't commented too well. The original developers had left the client company so there wasn't too much knowledge available. To spice up thing structure of the user interface was stored in the DB.

We managed to solve the rather interesting logic with debugger, some DB visualizing tools and plenty of mind map/relationship drawings on the paper. This was then documented in our wiki. But for some reason we did not create extensive test coverage to protect us - maybe the reason was that nobody really knew how the application and its business cases should work...

How people have dealt with similar cases? Are there any specific tools for understanding application or its creator's logic?

Answer 1

I did this a couple of times.

What really helped was to create a graphical representation of the datamodel. You can use tools, but sometimes creating it by hand is suitable because you will learn a lot while browsing through the code.

I tried sequence diagrams but those are not very helpful because they rapidly grow.

Answer 2

You could consider the answers to this question useful: http://stackoverflow.com/questions/205348/source-code-analysis-what-do-you-do

Do some diagrams, build up your knowledge. Start implementing small changes - this will get you to understand the system in no time

Answer 3

Most important is time, patience and curiosity.

Just dive into the code, take the feature you need to work on, or something else that strikes your fancy, and dig in. View the stuff you see with curiosity!! Be Nosy!!

Try to understand. "I wonder why he did it this way". "I wonder what this routine does".

And of course, try and document your findings!

Then try to change things, just to see what happens. Try to understand why it happens.

Build an understanding for the code base, for the programmer.

Answer 4

Start by writing unit tests. I approach this problem the same as validating a library for use in an application. The tests will confirm what the application's classes really do. The tests will also be the new documentation.

Answer 5

I've written programs to analyze source code to produce a database of cross-reference material.. Things like module and variable names, i/o files and where they are accessed (obviously for stuff older than a moder-day database).