The best way to familiarize yourself with an inher

Question

Stacker Nobody asked about the most shocking thing new programmers find as they enter the field.

Very high on the list, is the impact of inheriting a codebase with which one must rapidly become acquainted. It can be quite a shock to suddenly find yourself charged with maintaining N lines of code that has been clobbered together for who knows how long, and to have a short time in which to start contributing to it.

How do you efficiently absorb all this new data? What eases this transition? Is the only real solution to have already contributed to enough open-source projects that the shock wears off?

This also applies to veteran programmers. What techniques do you use to ease the transition into a new codebase?

I added the Community-Building tag to this because I'd also like to hear some war-stories about these transitions. Feel free to share how you handled a particularly stressful learning curve.

Answer 1

Pencil & Notebook ( don't get distracted trying to create a unrequested solution)

• Make notes as you go and take an hour every monday to read thru and arrange the notes from previous weeks

• with large codebases first impressions can be deceiving and issues tend to rearrange themselves rapidly while you are familiarizing yourself.

• Remember the issues from your last work environment aren't necessarily valid or germane in your new environment. Beware of preconceived notions.

• The notes/observations you make will help you learn quickly what questions to ask and of whom. Hopefully you've been gathering the names of all the official (and unofficial) stakeholders.

Answer 2

Do try to understand the code by fixing bugs in it. Do correct or maintain documentation. Don't modify comments in the code itself, that risks introducing new bugs.

In our line of work, generally speaking we do no changes to production code without good reason. This includes cosmetic changes; even these can introduce bugs.

No matter how disgusting a section of code seems, don't be tempted to rewrite it unless you have a bugfix or other change to do. If you spot a bug (or possible bug) when reading the code trying to learn it, record the bug for later triage, but don't attempt to fix it.

Answer 3

Go over the core libraries and read the function declarations. If it's C/C++, this means only the headers. Document whatever you don't understand.

The last time I did this, one of the comments I inserted was "This class is never used".

Answer 4

The first thing I do before going down into code is to use the application (as several different users, if necessary) to understand all the functionalities and see how they connect (how information flows inside the application).

After that I examine the framework in which the application was built, so that I can make a direct relationship between all the interfaces I have just seen with some View or UI code.

Then I look at the database and any database commands handling layer (if applicable), to understand how that information (which users manipulate) is stored and how it goes to and comes from the application

Finally, after learning where data comes from and how it is displayed I look at the business logic layer to see how data gets transformed.

I believe every application architecture can de divided like this and knowning the overall function (a who is who in your application) might be beneficial before really debugging it or adding new stuff - that is, if you have enough time to do so.

And yes, it also helps a lot to talk with someone who developed the current version of the software. However, if he/she is going to leave the company soon, keep a note on his/her wish list (what they wanted to do for the project but were unable to because of budget contraints).

Answer 5

One of the best ways to familiarize yourself with inherited code is to get your hands dirty. Start with fixing a few simple bugs and work your way into more complex ones. That will warm you up to the code better than trying to systematically review the code.

If there's a requirements or functional specification document (which is hopefully up-to-date), you must read it.

If there's a high-level or detailed design document (which is hopefully up-to-date), you probably should read it.

Another good way is to arrange a "transfer of information" session with the people who are familiar with the code, where they provide a presentation of the high level design and also do a walk-through of important/tricky parts of the code.

Answer 6

One thing vi and emacs users can do is use tags. Tags are contained in a file ( usually called TAGS ). You generate one or more tags files by a command ( etags for emacs vtags for vi ). Then we you edit source code and you see a confusing function or variable you load the tags file and it will take you to where the function is declared ( not perfect by good enough ). I've actually written some macros that let you navigate source using Alt-cursor, sort of like popd and pushd in many flavors of UNIX.

BubbaT