Code Reviews in Crunch

Code reviews are important (yes, really). If you have a code review tool like Rietveld, Crucible or CodeStriker it is nice to have a central place to do code reviews, especially for a large team. But how often to do the code reviews and is there time?

The benefit of code reviews is difficult to measure and is different from team to team. In a large team with hundreds of thousands (or millions) of lines of source code, no one individual knows all the code, and duplication of code often will happen for those unaware that the functionality already exists. Code reviews are useful for both the reviewer and the reviewee as it shares knowledge and gives feedback on the code quality and implementation. Unfortunately, like many practices during a crunch, code reviews are often one of the first to go. This is understandable, but is important to maintain some form of code reviews throughout the project, especially for crucial pieces or for the more junior developers. They don't have to be as formal, but a quick sanity check of the code your tired developers is putting in will help catch some bugs, flaws in design and other aspects that happen when a project is rushed.

Some people would suggest code reviews for every check in, but I feel it depends on the team. Knowing that someone will review your work is helpful in maintaining a high standard, but at least doing a few key ones with some random spot checks will hopefully help catch a number of issues. Even if team wide the time spent doing code reviews a few hours a week, it will at least bound to catch a few things, and teach you more about the code.

If your project (for some reason) hires new people onto it while in crunch mode, one of the best things you can do is have the person on (nearly) full time code review. This benefits in a few ways. First, the new developer will learn what kind of code is expected, what is being worked on, who is working on it and how the code progresses. Second it will give you information about the new developers skill set, by what kinds of questions they ask and what kind of comments they make. Third, it keeps the new developer out of the code base for a little while, since unless there is something trivial to do, a new developer is more likely to take time away from others with questions and training then they are able to contribute. At least one senior developer should still spend some time as part of the code review, but limiting their time in a crunch is understandable.

If you aren't doing some code reviews, it is a beneficial practice. More time is often spent reading code than writing it, so giving feedback and making the code the best it can be, will help in both the short and long run.

Keep on reviewing,
Michael Hubbard
http://michaelhubbard.ca