Understanding Other People’s Code

Posted on November 14, 2011 by Alfredo Scaini

Most of us have been there – being assigned the job of fixing or enhancing the functionality of someone else’s project. Someone whose code you’ve never encountered before; someone who you may not even know … someone who did not leave any documentation!

Oh … and you have to have the changes done in a few days.

Step 1: Get an Idea of What the System Does

Before you go into the code, ASK if there’s any documentation regarding this project. You never know – if a developer didn’t create any, an information architect may have. If there were any technical requirements or project charter these would be a great place to start as well.

Download a copy of the system to your development environment and try it out – play with it to get a sense of what the system does and how it functions. If there is documentation, compare the documentation against what the system does. I would hazard to say that 75% of the time the documentation is either out of date or 180 degrees away from what the system actually does, but that doesn’t mean you shouldn’t look at it. Just don’t trust documentation fully – trust in the code.

Step 2: Go Into the Code

Now that you have kind of an idea of what the system does (or was suppose to do), open up the source code and take a look at how the file structure is set up. Look for class files (model), presentation files (view) and logic files (controller) … might even all be in one file! You’d be surprised – people with a bit of experience under their belt follow the MVC pattern often, even when they don’t realize it.

When you set this up on your system you should have done some preliminary rummaging through the source files to find any configuration files. Now take a closer look at this config file and see if it’s more than just a config file. If there isn’t any configuration file(s) just bow your head in disappointment … portability was not a consideration for this app.

Break it Up into Smaller Chunks

If you’re overwhelmed by the scale of code, then break it up your study into smaller modules. Look at one user interface and the immediate code associated with it – get a sense of the kind of variable names the programmer uses, how he/she structures their logic statements and how things are organized. This will help you when you dig deeper in the code.

Look for Comments

Do a search for “//” or “/*” comment tags and hope that the programmer used them.

I always worry about those programmers who proclaim, “my code is my commenting” or those that complain that they didn’t have time to comment. It doesn’t matter how good a programmer you are, commenting processes and complex business logic will help you and future programmers that have to work on your code.

Make it a habit – add meaningful comments to your code that explain why things are being done a certain way and the implications of not doing it this way.

Side Note: Commenting is a good practice as it forces you fully understand a complex process because you’re now faced with having to explain it. If you can’t explain what your code does, then its a sign you’ve not thought things through and you need to revisit how your going about writing this block of logic.

Step 3: Ask Your Peers

When you see something that totally has you stumped, ask your peers to take a look. Everyone has different strengths and weaknesses and other people come in with a fresh set of eyes.

I know that there were a few times when my explanation of the problem to a colleague helped me figure out the problem on my own – I just needed to talk it out. They’re response, I'm glad I could help out :)

Step 4: Don’t get Discouraged

Failure is an ever present risk when working with someone else’s code. The thought that you might not be able to complete the assignment because you can’t understand someone’s code can be a real morale downer.

Try to stay positive and focused on figuring things out. This is important. When you feel that things are hopeless then you will fail. Remember, your team is your support group so ask them questions. Also, break the app up into smaller chunks and go at it piece by piece.

A project delivered late, while not great, is definitely better than the prospect of a project not delivered at all.