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 ReviewsEvery 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:
- Get assigned an issue
- Create a new branch
- Do the work
- Create a pull request and assign the issue to another developer for code review
The reviewing developer:
- Review the diff
- Check out the code locally or review a staging server to confirm that the code functions as expected
- 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 StrugglesThe problem we’ve often run up against is that the reviewing developer often doesn’t have enough context to effectively review the code.
Group Code ReviewsOne 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.