Peer review
Peer review also serves as an enabler for spreading knowledge across the team: reviewers learn about parts of the system they may not have known, and those whose work is reviewed learn about alternatives and good practices.
Origin
Although this technique comes from scientific publishing, where it has been an integral part of the publication process since the mid-20th century, it has taken root in software development. References to it can be found in CMMI guides (in the Verification Process Area) and in Eric S. Raymond's book The Cathedral and the Bazaar.
Basic considerations
It is advisable to keep the following basic considerations in mind when introducing this technique in a development team:
- Peer reviews aim at the early identification of errors, so they should be carried out incrementally as stages of development are completed: several small reviews are better than a single review at the end of development.
- The focus of peer reviews must always be the code, not the person who wrote it.
Building on these principles, peer review systems of varying complexity can be built:
| Type | Advantages | Disadvantages |
|---|---|---|
| Individual | Very simple to implement | May give rise to tacit non-aggression pacts. May cause conflicts between author and reviewer. |
| Group | More effective than individual review systems. Encourages collective code ownership. | A leader figure may emerge and reduce the method's effectiveness. Some authors feel uncomfortable with this type of review. |
Focus on what matters
For the review to be effective, it is advisable to focus on the aspects with the greatest impact:
- Business logic: Does the implementation deliver what the user story or spec asked for?
- Edge cases: Does the code correctly handle boundary cases and errors?
- Readability: Is the code understandable to any team member?
- Security: Are there any obvious vulnerabilities?
- Duplication: Is there repeated code that could be abstracted?
Automated static analysis tools can handle the more mechanical aspects (formatting, style, and complexity metrics), freeing the reviewer to focus on the aspects that require judgement.
Preparing the review
The effectiveness of the review depends partly on preparation:
- The author must make sure the code compiles, passes the tests, and has sufficient comments before requesting the review.
- The reviewer must have access to the context (the user story, the spec, or the acceptance criteria) to judge whether the implementation is correct, not just whether it is well written.
- It is recommended to limit the size of pull requests to what can be reviewed in a 30–60 minute session. Very large pull requests reduce the quality of the review.
Peer Review of AI-Generated Code
The reinforced DoD for teams working with AI includes human review of generated code as a mandatory component. Peer review of AI code has specific characteristics:
- AI-generated code may look correct and complete on the surface, yet introduce subtle errors that appear to be a valid solution. The reviewer must be especially careful with business logic.
- AI tends to generate duplicate code: the review must verify that no unwanted duplication has been introduced.
- Part of the review can be automated by using other AI agents as reviewers (AI supervising AI), but the final validation of business logic requires human review.
Common mistake
Reviewing style and formatting instead of behavior. Linting and static analysis tools handle style automatically. If peer review focuses on code formatting rather than logic, the team spends reviewers' valuable time on something a machine already does, and overlooks the defects that only a human can detect.
References
- Raymond, Eric S. (1999). The Cathedral and the Bazaar. O'Reilly Media.
See also
Do you want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.