To run a successful code review, your first step is to ensure that the code review happens. The code review process typically is among the first items jettisoned from a project, Heusner sighs, "Usually right before someone trims to less than a week for a four-month e-commerce project." That can occur even in software development departments where the team personally cares about quality. Any mention of "code review" elicits comments like, "Wouldn't it be great to do them?" or "I heard someone did one last project" or "Is it worth the effort and money to hold code reviews since anyway?"
But it's one thing to say you're going to do code reviews. And it's another thing to know how to go about the process right, so that the end result is the best, most joyful application possible. Ideally, you also build a collaborative team environment, create a more responsive development process and, oh yeah, have more fun at work. In this article (and its accompaniments), I share the wisdom gathered from dozens of passionate software developers (oh boy, are they passionate!) about when and how to do code reviews, who should sit at the table and the dire consequences when code reviews are done wrong. And incidentally, they are done wrong a lot.
I've tried to make this a definitive guide to code reviews, which means that I've split the various issues into several articles. That lets you can focus on solving the problem that's getting your shorts twisted into a knot. But I like to think you'll want to read the entire thing; you don't have to do so in any particular order. Here's everything in this package:
Running an Effective Code Review (this article)
Reasons to Do Code Reviews