Thursday, October 25, 2012

Code Review Best Practices - Live Code Reviews

Most of the time, I prefer using tools like Crucible for conducting code reviews because they allow you to think through the code on your own time, at your own desk. You can read a chunk of code, think about it, scroll around the file, and if you're so inclined, comment on it. And the next person can do the same.

But there are times when a code review needs to be done in person. Maybe you don't have code review software, or maybe the code change is urgent. For those cases, here are some lessons I've learned.

Allow the reviewers to look over the code on their own beforehand

If you're reviewing someone's code, you need time to be able to look over it properly. Live code reviews are typically rushed. When they're done ad hoc, you're usually eager to get back to your own coding. If they're scheduled, you're racing against the clock.

By allowing the reviewers to read through the code on their own, they can take time to mull things over, to pull up an online reference, or to poke around in other parts of the app that might be affected.

Three people should be present

They say "two's company, three's a crowd," but during live code reviews, "two's an argument, three's a discussion." When only the author and the reviewer are present, the tendency is for opinions to polarize. But when you've got the author and two reviewers, it feels more like a game of hacky sack. You kick an idea around.

Four people is too many. Conversations are derailed way too easily when that many people participate at once.

Create room to think

Some developers think most clearly when they discuss something verbally with others. But many of us, I believe, think most clearly when we're not engaged in conversation. The reason is that conversation involves three activities: talking, listening, and formulating thoughts. It's difficult to do even two of them at once, and to do them well.

  • When someone else is speaking, listen. Do not think about why they're wrong or what you're going to say next -- just focus on understanding them. And whatever you do, do not interrupt!
  • When they're done talking, that's when you can start formulating your thoughts about what they said. Be comfortable with 20-30 seconds of silence here. Many people feel inclined to break silence after only 2-3 seconds.
  • Once you've formulated a thought, speak it.

Sound easy? Give it a try. This kind of etiquette is even more important in code reviews than in casual conversation.

Again, I prefer the software-based code reviews, but for those times when you've gotta do it live, I hope these practices are as helpful for you as they've been for me!

No comments:

Post a Comment

Profile Picture
Dave Leeds
My Hobbies:
  • Programming
  • Cartooning
  • Music Writing
Full Profile