Occasionally a client will ask me for a recommendation: Should our team perform peer code reviews or group code reviews? There are advantages to one over the other, but the correct choice depends on your development team’s situation. Let me start with an overview of the two approaches. Group Code Review A group code review is when […]
Occasionally a client will ask me for a recommendation: Should our team perform peer code reviews or group code reviews? There are advantages to one over the other, but the correct choice depends on your development team’s situation. Let me start with an overview of the two approaches.
A group code review is when one developer’s code is reviewed by the rest of the team together in a conference room, screen share, or gathered setting. The rest of the team provides constructive feedback on the developer’s code in the spirit of feedback for improvement.
It is important not to overlook or underestimate the power of group code reviews. This approach to reviewing code engages the individual developer, the team, and team’s leaders in ways that bring experience and judgment to uncover issues and improve design.
An effective group code review focuses on all the areas of code analysis that the automated tools and techniques are weak at evaluating. Let the automated tools perform the fundamental or clerical review. The group review should spotlight how the source code is or is not matching best practices and good design. The discussion is a transfer of knowledge from the more experienced to the less experienced developers. The experience, expertise, and judgment inform improvements to the coding in ways that go beyond the ordinary and routine analysis, such as following the coding standards, and toward improving coding technique and better design patterns.
If done well, the group code review is a communication vehicle that opens up a healthy dialog on the chosen conventions and why adherence is important. The best techniques associated with group code review bring learning and education to the team.
A peer code review is when one developer’s code is reviewed by another developer – someone who is considered a software development peer. The two developers get together at the same desk or share the screen. The peer provides constructive feedback about the developer’s code in the spirit of feedback for improvement.
The peer review is similar to the group review in many ways, but the peer review is a discussion between two colleagues. Each must respect the other’s experience, expertise, and judgment. The developer is looking for a peer to go over the code to validate the solution and to evaluate suggestions and recommendations.
If done well, the peer code review is a supportive dialog between colleagues that ensures thoroughness and correctness. The best techniques associated with peer code review bring idea sharing and professional dialog to the team.
The main advantage of group reviews is that this approach can be an excellent learning experience. If done well, the team learns and grows together. The disadvantages are that the team members who are involved in the group review are diverted and distracted. The issues found during the group review are documented and tracked; however, the follow-up and follow through is not always good.
Sometimes, if they are not done well, the group reviews can become too judgmental and invasive for the developer under review. These can be unpleasant and are quickly abandoned.
The main advantage of peer reviews is that this approach is time effective. If done well, the reviewed developer’s code is validated by the reviewer. This is because they have collaborated previously on the design and the solution strategy. The code review is a continuation of their collaboration. Any issues are addressed immediately, so the follow through is handled on the spot.
Sometimes, if they are not done well, peer code reviews are missing a few key elements. It isn’t peer review if the developers are not peers; there’s no collaboration and dialog. The review must be taken seriously and be beneficial to both the developer and the reviewer.
When there is the need to do a lot of teaching on the project, I recommend a group code review approach. Everyone gets a chance to hear and observe what is being taught. By using the code-under-review as an example, many team members find this approach to be a helpful and relevant learning aid.
For teams that have a lot of developers with many years of experience, it is more time efficient to have people review code in pairs. Also, since any changes or issues are resolved in real-time, the time from identification to resolution is much shorter. When you have a team of experienced developers, perhaps the best reason to have peer code reviews is that they improve each other’s development skills while getting the coding done.
What is your preference for code reviews?
Source: Stephen Ritchie, Pro .NET Best Practices (New York: Apress, 2011). Excerpted in part with permission of the author.