Sure, deep down I know that code reviews are good for me - data and conventional wisdom show that they can reduce defects, improve code quality, eliminate redundancy, and spread key project knowledge across the team. But then again, I know that dieting, writing my congressman, and visiting grandma are good for me too, and sadly I don't really do those things either.
The problem is, like with most things that are good for me, the typical Fagan-style code review takes a lot of time and discipline - two things I have a shortage of. Instead, what I want is a code review process that's more light-weight - something that has many of the benefits, but fewer of the costs. Code Review 2.0, if you will! (Ok, maybe not with that name, but definitely something different.) Specifically, I need something that's less rigorous than the standard code review, more breadth-oriented than depth-oriented (maximizing code coverage), and a bit less tedious for the participants.
That's what I was looking for on a recent project at least, and I came up with something that worked for us. I call it the Code Review Potluck. Here are the rules:
Step 1 - Prepare: Wouldn't a Potluck dinner suck if everyone brought over the same recipe of Meatloaf? Well, it's the same for code reviews - they're way more boring and less effective if each developer makes the same comments on the same code. For that reason, in a Code Review Potluck each developer focuses on where ever they are in the code that week, and prepares a list of 4 questions, 4 code quality concerns, and 4 kudos to share with the group. To be clear, here's what I mean. "Questions" are really problems, but for the purpose of tact, we phrase these as earnest queries. "Did you mean to put 3000 lines into that method named doStuff()? Really?". Next, "code quality concerns" are braces and spaces type stuff. Limiting these to 4 is key - no one wants to sit in a meeting and hear Ted list off every instance of a method I forgot to comment. Trust me. I got the point. And lastly, "kudos" are crucial. Just like in any friendship/partnership/marriage, the more good things you say about me, the more I'm willing to listen. It's just human nature. Try to find something nice about what I wrote ("wow, your use of the semi-colon is very smart!"), and I'll better remember your abstruse Javadoc pecadillos.
Step 2 - Enjoy: At the Code Review Potluck, each developer takes a turn sharing their list of goodies. For every item, we all look at the code (i.e. on projector or laptop) and discuss for a few minutes what's going on. "Do you agree that aggregation would be better than inheritance here? What do you think about this naming convention?". And so on. It's important, as Mom told us, not to play with our food - time is of the essence. Make your points, discuss a bit, and move on. In general, an hour for the Code Review Potluck is plenty. Less is more.
Step 3 - Digest: After the Potluck's over, one person gets the honor (read: burden!) of posting the questions/concerns/kudos and thier respective resolutions to the Wiki (you do have a Wiki, right? If not, email will work). Each developer then strives to make changes to their code later in the week, but let's be honest, there are no real guarantees (this a light-weight process, remember?). The real value of the Code Review Potluck is the digestion of the conversation itself. After spending an hour talking about code you'll hopefully have picked up some new tips, tricks, and practices that you can apply the next time you spend some quality time with your IDE.
Like all things "good for you", it's best if you make Code Review Potlucks a habit. Once a week over lunch was reasonable for our team. The more you do it, the easier it'll be.
That's about it! There's of course so much more that could be pontificated on regarding code review practices, benefits, costs, etc - but why make things hard? The Code Review Potluck can be a simple, helpful, and fun mechanism for improving quality on your projects. Good luck!
- Best Kept Secrets of Peer Code Review: Jason Cohen
- Code Complete - Steve McConnell. Chapter 21.3: Formal Inspections
- Peer Reviews in Software: A Practical Guide, Karl Wiegers (November 2002)
- Part of Your Complete Breakfast: Code Review is a Source of Essential Vitamins and Minerals, Stephanie Lussier (2002)
- Pair Programming vs. Code Reviews, Jeff Attwood (November 2007)
- What Makes a Code Review Trustworthy?, Stacy Nelson and Johan Shumann