Dealing with a Legacy Codebase

As software engineers we don't always get to work on clean slates.

At one time or another, we all get to deal with legacy code bases. Eventhough they may look like scary daemons at the first sight, they can be fun and they can teach us a lot of things. 

We all love to see clearly written, easy to read, properly formatted, well maintained code that are well aligned with all design standards imaginable and backed with clear and up-to-date design diagrams, architectural documents, requirement specs etc. But such legacy code exists only in the day dreams of developers. In reality, no matter whether you're in silicon valley or in a outsourcing company in far east, what you get is a soup of technologies, very very lengthy classes with bug fixes creeping in and messing up the original design whatever it was. You'd be lucky to find any documentation. And even the domain knowledge is tuned into software folklore that are passed from developer to developer and lost when people leave.

How do you get to know a legacy code base in practice? 

Bug fixes & Debugging 

One of the best hands-on-approaches to learn a foreign code, is to fix something in it. A bug will give you a purpose and a direction. The more you go wrong, the more you learn. Following the code along with the variables through debugging gives a good idea about the code.

Reverse engineering the design

There are tools that allow you to create design diagrams based on existing code. These diagrams help you to visualize the overall picture.
You can draw class, sequence diagrams by simply dragging and dropping the classes. ObjectAid is a free Eclipse plugin that allows you to do that.

More advanced tools would generate the diagrams when you run the functionality.  MaintainJ is one such tool that gives some of the functionality free. It's a Ecplise plugin again.

Use of profiling tools

Profilers generate the call tree along with the times spent at each step. You get the class/method stack that gets called when you run the program. It's a great way to find out which classes and which methods gets called in a given scenario.

Eg: JVM Monitor

History and folklore

There is a wealth of knowledge floating around that is not included in the code or in any of the documentations. These exists in the memory of the people who had been dealing with the system for some time.
There are pretty interesting stories about why a certain functionality had to be implemented that way and not in a different way etc. "Long time ago when dinosaurs roamed the earth there was this requirement and we did this to cater for that, hmm nobody needs that any more, but we never had the time to remove it", Dead Code?, yeah don't be surprised if you find skeletons and cemeteries in your code base!

Talking to people and getting to know all this background details is critical, and the juicy bits in the stories actually make all the technical nitty gritties stick in your memory.