|Photo by Sebastian Bergmann|
How do we do code reviews, concretely? Some companies have very drastic processes in place. For example, they won't allow anything into their master branch without a code review. And there's nothing wrong with that.
At Orbeon we have implemented something a little bit more lightweight. We do reviews on weekly basis. Each Friday afternoon we stand around each other's computer (yes, stand!), and we review every commit pushed to github since the previous review.
The programmer who has written a given change is the driver and explains the rationale behind it, pointing to non-trivial aspects if any. This results in discussions and feedback such as:
- Discussing whether there might have been another (maybe simpler) solution to a problem.
- Improving naming (one of the hard things in computer science).
- Requesting that non-obvious code be commented better.
- Discussing and explaining programming patterns.
- Catching obvious little errors.
We don't review necessarily every single line of code. Some changes can be complex (hopefully for good reasons) and it would take too much effort to dig all the way down. But at least we get an idea of the intent of the code.
In the end, what do we gain? A better understanding of our code base, especially parts we are less familiar with; action items to improve code we have just written; and finally, we learn and, I think, become better programmers. It's probably worth the 1 to 2 hours a week we spend doing reviews!