Code Review 2.0

Karen AdkinsI received this email from one of my team members.  Really good food for thought.  I would love to hear from you if you try it out and it works!!!

 “As you may remember, I strongly believe in the benefits of code reviews.  This guy has an alternative to code reviews which could be more conducive to our way of working.  Just food for thought.  :D

 Building a better code review

Over the years, I’ve worked with a process that I’ve come to call code workshops (since code reviews have a negative connotation, a different phrase eliminates some bias). Code workshops are a group session that are intended to socialize team expectations and best practices, as well as uncover issues and points that need to be addressed by the team as a whole.

Code workshops take place on a weekly basis for one hour and with a maximum of 20 people in the room. The session is split in half, with two reviewers each reviewing a file (or set of files, if small enough) for 30 minutes. The key pieces to the meeting are:

  • A reviewer is assigned (or selects) a piece of code to review ahead of time. The reviewer must choose a file that he or she didn’t write. It’s the reviewer’s job to present the work of someone else.
  • The reviewer reviews the entire file, not just diffs. Diffs are okay for bug fixes but to get a deep understanding of the code, you need the extra context. The goal of the reviewer is to learn as much about the code as possible.
  • The reviewer reviews the code before the workshop. I typically recommend people set aside an hour for this. During that time, the reviewer adds comments directly into the file marked with REVIEW.
  • The meeting begins with everyone closing their laptops except for the reviewer and one other person to take notes. The point is to have everyone pay attention to what’s being discussed so we don’t waste anyone’s time.
  • In the meeting, each reviewer goes over the file with their comments, focusing on the interesting pieces of code. The code is projected so that everyone can follow along.
  • The reviewer cannot mention people’s names during the review. The point is to review code, not people. Everyone is considered an owner of the code so there is no need to get defensive. If there are problems in the code, then the group needs to get better as a whole.
  • It’s the reviewer’s job to encourage discussion through findings in the code. Look for interesting or problematic patterns, opportunities to establish new conventions, or pieces of the code that need more explanation.

After the meeting, notes are sent out to all of the participants and relevant documentation is updated (if, for example, new conventions emerge).”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s