Group Code Reviews

Code reviews help assure quality. They’re also an invaluable professional development tool. Important as they are, we’ve always struggled implementing a successful code review process at Aten – but that's changing. Over the last few months our front-end team has been doing group code reviews and they've already proven to be useful.

Traditional Code Reviews

Every place I’ve worked with a successful code review process was an organization where a team of engineers, with overlapping disciplines, worked on the same code base. A typical code review process might have looked like this:

1. Get assigned an issue
2. Create a new branch
3. Do the work
4. Create a pull request and assign the issue to another developer for code review

The reviewing developer:

1. Review the diff
2. Check out the code locally or review a staging server to confirm that the code functions as expected
3. Approve the work or assign back to the original developer with feedback

In order for the reviewing developer to provide useful feedback, he or she must have a pretty good understanding of the the issue at hand, goal of the code, organization of the codebase and coding standards used on the project. Otherwise, you’ll end up with the same types of code style feedback you can just as easily automate with linting.

Our Struggles

The problem we’ve often run up against is that the reviewing developer often doesn’t have enough context to effectively review the code. Aten is a client services company. We have many teams working on different projects at any given time. Depending on its size, there can be anywhere from one to four developers collaborating on a project. It's rare that we have multiple front-end developers working on a project at once. So when it comes to code reviews, we often run into issues with finding someone to review code that has a good understanding of the discipline (JavaScript, SCSS, PHP, etc.) and enough knowledge about the project to properly review the functionality and code intent.

Group Code Reviews

One of our front-end developers, suggested we try a group code review. During our weekly front-end team meeting (a.k.a. Club FED) we invite developers to a show & tell of sorts. We gather around the big screen in our conference room. A developer walks through an issue and intended functionality. This gives everyone context about the project and problem being solved. The developer also walks through the code, explaining their approach. Then as a group, we can ask questions and provide feedback. It’s as simple as that. The benefits became clear after our first meeting.

• The feedback we could provide as a group was much more valuable. Four devs are better than one. If I didn’t see some way of improving on the work, someone else did.
• There was much more knowledge sharing. In every case so far, the problems and solutions were new to at least one of the developers involved. Making this a learning opportunity.
• As someone leading a team of developers working on independent projects, the group review process gives me much more insight into what each team member’s strengths and capabilities are.

I’m looking forward to seeing how this process improves over the year. So far, we’ve already found our initial attempt of 10 minutes per person was way too short. Each person needs at least 20 to 30 minutes to provide enough time for explanation, discussion and feedback. If you’ve also struggled implementing a good code review process with your team, I’d definitely suggest trying a group code review. Even if you have a good review process in place, it may be worth trying a group review just for the knowledge sharing benefits.