Code Review Techniques Overview

Code Review in Pull Requests have become a de facto standard today. While these tool-assisted asynchronous reviews certainly improve the code quality, they come with certain costs, nicely described e.g. by Dragan Stepanovich in his article.

I will not repeat his arguments here. Instead, I would like to provide an overview of alternative ways of reviewing code. They come with different costs and benefits.

First, let’s summarize what is the essence of the Pull Request review. The author forwards their code to several other people, asking for feedback. The reviewers answer (or not) in a certain time period with comments to the artifact.

Even with tooling support, this is a non-interactive technique with delays and prolonged feedback cycle. Other techniques listed below provide a higher level of interactivity.

Pair/mob programming

In a pair programming session, two people work together to develop an artifact, typically code. Only one person would be coding at any point, with the other observing, questioning assumptions and otherwise providing support. This means that there is a continuous, informal review of the artifact as it is developed.

As such, the code review is instanteous, reviewing each line of code as it is being written. Also, it draws on the wisdom of two people (more in case of mob programming). Typically, every person focuses on a different aspect of the artifact, which leads to improving its quality in multiple aspects simultaneously.

Post-merge code review

Some teams let the programmers merge their code to the integration branch without review and then organize a regular post-merge review of all changes that happened in the meantime. A typical frequency is once a week or once a sprint.

They go through the changes files and component and discuss their current quality. As an advantage – they can see and discuss the broader context, not only the changed code, but also the unchanged code. In other words, they can see that code as it is now.

This can also be a drawback. If they don’t know the history and context this can mislead their judgement. Therefore, it is better if author of the recent changes is present in the session.

Walkthrough

An author describers their work artifact to a group of peers and gathers their feedback. The reviewers listen to the author and provide immediate feedback to the artifact. The author has a chance to introduce some concepts behind the artifact and the reviewers can understand it on a deeper level.

Session code review

A more formal variant of a walkthrough. An author sends an artifact in advance and collects all feedback. The participants have time to prepare by reviewing the artifact in isolation first. After collecting the feedback the author organizes a session where feedback findings are discussed one by one and either approved or rejected.

There can be more formal variants of the session review, where every participant has a role and focuses on a different aspect of the artifact, e.g. security, grammar, performance, etc.

Conclusion

Code review is older than pull requests. By catching potential issues, code reviews play a crucial role in producing robust and efficient software. However, different techniques come with different benefits and drawbacks. It is good to know them to be able to choose the right technique for the task at hand.

Leave a Reply

six + fifteen =