Monday, August 24, 2009

Dynamic code reading

Recently, I've been digging into a new body of code.

As a result of a sequence of events, I've picked up responsibility for a large body of existing code, and the original author of that code is not available to me. This is not the first time this has happened to me; in fact, this is actually a fairly common circumstance in the software industry, and if anything it's a bit of a surprise that this doesn't happen to me more often.

At any rate, I'm faced with the prospect of learning how this code works, learning where its strengths and weaknesses are, and then constructing a proposal for where to take this code in the future.

My first milestone is to take the existing test suites, verify that I can run those suites, and then try to make those suites run faster and more reliably. I'm lucky: the project was left in a state where the code compiles, and the tests mostly run. Even better, there are a fairly substantial set of tests. So this is a good situation to start in.

My other first milestone is to fix a bug. I've even identified the bug (well, actually, somebody else picked the bug, which is even better, because they picked a bug which matters to a particular user, which is a good way to choose a bug).

So now I just have to learn the code, fix the bug, run the tests, and submit the fix to the various branches of the SCM system.

Of course, that's easier said than done. And the idea behind this post was to talk about how I go about learning a new body of code.

One thing you can do is to sit down with your editor and start reading the code. This is fine, and in fact I'm actually a pretty good code-reader. I've been reading code for 30 years, and in general I think I'm a fairly effective and rapid code reader.

But that's not my preferred way to learn code. The best way to learn code, I've found, is to step through it in the debugger. There are a bunch of advantages to this approach, such as being able to look at the values of the variables while the code is actually running, but the most important reason for using a debugger to step through code while you're learning it is that the debugger will help you figure out:
  • who calls this code
  • when do they call it
  • why do they call it? (that is, what does the caller do with the results?)
These sorts of questions are terribly hard to figure out when you are just statically reading code in your editor, particularly in an object-oriented language where overridden and overloaded methods, interface-implementation abstraction layers, and the like make it terribly hard to look at a method call in your editor and figure out where that call is actually going to take you.

So, my suggestion is: if you are trying to learn a new body of code:
  • set up your debugger
  • construct an interesting test case
  • and start stepping through code!

No comments:

Post a Comment