The best way to familiarize yourself with an inherited codebase

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

Answer 1

I've dealt with this issue many times. I ended up writing a blog post about a general process to follow for learning a new codebase: http://www.larsavery.com/blog/a-process-for-learning-a-new-codebase/

Answer 2

create documentation for each thing you figured out from the codebase. find out how it works by exprimentation - changing a few lines here and there and see what happens. use geany as it speeds up the searching of commonly used variables and functions in the program and adds it to autocomplete. find out if you can contact the orignal developers of the code base, through facebook or through googling for them. find out the original purpose of the code and see if the code still fits that purpose or should be rewritten from scratch, in fulfillment of the intended purpose.

find out what frameworks did the code use, what editors did they use to produce the code.

the easiest way to deduce how a code works is by actually replicating how a certain part would have been done by you and rechecking the code if there is such a part.

it's reverse engineering - figuring out something by just trying to reengineer the solution.

most computer programmers have experience in coding, and there are certain patterns that you could look up if that's present in the code.

there are two types of code, object oriented and structurally oriented.

if you know how to do both, you're good to go, but if you aren't familiar with one or the other, you'd have to relearn how to program in that fashion to understand why it was coded that way.

in objected oriented code, you can easily create diagrams documenting the behaviors and methods of each object class.

if it's structurally oriented, meaning by function, create a functions list documenting what each function does and where it appears in the code..

i haven't done either of the above myself, as i'm a web developer it is relatively easy to figure out starting from index.php to the rest of the other pages how something works.

goodluck.

Answer 3

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 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

Write unit tests. You'll find the warts quicker, and you'll be more confident when the time comes to change the code.

Answer 6

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".