How to approach huge code base of undocumented code?

Question

I have recently been assigned a project to further develop an existing code base. The code doesn't contain any tests and not even one single line of comments. The whole "thing" is written in a really obfuscating manner so it takes a lot of time to figure out what happens.

How do you usually approach this kind of problem? Tips and trix on how to handle this situation?

Answer 1

Here's a list of code comprehension tools.

Answer 2

One chunk at a time.

When you have to make modifications, write tests around what you are modifying. Then make your change safely. Over time, you end up with cleaner code, that's got tests.

Answer 3

The way I'd do it is to clean up the code if it's not already cleaned up (align the braces and so on.) Most decent text editors have this feature built in (eclipse, netbeans.)

Then I'd probably browse around the application and trace where the logic takes me, have a cruise around the code and make myself familiar with how the previous developer(s) handled things.

Answer 4

One function at a time. Assume little and comment (to yourself) as you go. I just did this recently as well - given a 'c++' program that basically is 99% c with the main module written in 1 monolithic class. Given enough time, you will become familiar with the code and will be able to jump around in it somewhat comfortably. Just don't start changing things on for the first week at least. Until you know exactly what's going on, you will be shooting yourself in the foot later.

It won't be that bad in a few days :)

Answer 5

Does it have source control? Look through the history of changes.

If not, PUT IT IN SOURCE CONTROL. You WILL, inevitably, make breaking changes. Lack of documentation of expected behavior guarantees this. If you are diligent in checking in your changes as you go, you will be able to roll back and redo.

Create documentation as you go. As you learn what the code does/is expected to do, document it.

Answer 6

If it's in a runnable state, one approach is to set a breakpoint near the beginning of the application and step through a typical execution in a debugger to see what the code actually does (as opposed to what you think it does).