Much of my development involves reviewing and reading code, both formally and informally. You will only write code once, might modify it a few times, but you will read it over and over. I found code reviews are just a formalization of this code reading process.

I’ve noticed a few different types of code reviews, all based on what the goal of the review is.

Getting to Know You Code Review

The Getting to Know You code review is done so you can understand what the code is doing in general. Typically these are done on an entire application or library as a whole, where there is a large volume of code to review.

The goal of this is to get to know the code and be able to navigate around. What I try to do is to get a good understanding of the major components and how they interact. For Ruby on Rails applications this means the relationship between:

• the urls (routes) and controllers – how the users will see the application’s workflows
• the controllers and the models – how the data will be retrieved and updated
• the models to other models – how the data is related

A few things to watch out for are God Objects, too many classes, two few classes (both symptoms of design problems), and a lack of tests.

We Have a Problem Code Review

The We Have a Problem code reviews are a different beast. These come up because of a specific problem in the application: maybe there is a bug, performance has degraded, or a (human) process has gone bad.

This type of code review is very similar to the process you use when trying to reproduce a bug, in fact I’d consider reproducing a bug to be a code review of sorts. Typically these code reviews follow a process like:

1. Create a hypothesis of the cause of the problem,
2. attempt to either prove or disprove the hypothesis through experiments,
3. review the results,
4. Refine the hypothesis and iterate or discover of the bug’s root cause.

(This is similar to the Scientific Method)

Typically you’d start with a very broad hypothesis and narrow it down as you cycle through the steps. Finally you’d hone in on the problem areas and then have enough to be able to come up with a solution.

When you compare this type of review to the Getting to Know You, the We Have a Problem has a few major differences:

• the goal of this is to find a problem so it can be fixed
• the code needs to be understood just enough to solve the problem
• the review starts very broadly and then narrows down its search quickly

So in this case, the code review is merely a means to an end, fixing the problem.

The Refresher Code Review

The Refresher code review is designed to get back up to speed on how some code works. You might have written the code in the past, or maybe it is some code you’ve used before. In either case, the code is familiar but you need to do a quick review to become reacquainted with it. Typically these reviews are short, very informal, and most developers do them without thinking about them. Whenever you open up a class and scan through its methods and data, you’re doing a Refresher code review.

There isn’t much to say about the Refresher. It’s a lot like the Getting to Know You in that it can be broad, but it’s like the We Have a Problem in that you might only focus on a few classes or objects.

The important thing to remember is that the Refresher’s goal is to help you understand a section of code again so you can work on something.

Many Subtypes

These are a few different types of code reviews that I do and have seen other people do. They encompass many of the different reasons someone will want to do a code review and there are a few subtypes of code reviews that are used in specific cases. Like starting a rescue project (Getting to Know You) or a security audit (We Have a Problem). There are probably other major types of code reviews but these are the ones I come across again and again.

There is one final type of code review that I think developers should do more of (no, not a dramatic reading of the code)…

One Last Type, For Fun

That’s doing a code review for fun, enjoyment, and to learn. Sitting down with a chunk of code, a tasty beverage, and spending an hour reading and reasoning through some code just for the fun of it. I’ve done it with prototype.js, Rails, and capistranio in the past and that knowledge is still helping me today.

[box type=”tick” style=”rounded” border=”full”]If you’ve never done a code review for enjoyment, post what you’re interested in (topic) and what programming languages you know in the comments below and I’ll try to make a recommendation for you.[/box]

They don’t take a lot of time and you can do them with very little equipment (I’ve printed out code before and also read some on my iPad).