There are different types of Code Reviews with different objectives. This article only refers to those Code Reviews that another team member does before incorporating the change in the shared code repository.
The objective of these reviews is to improve the quality, avoid errors introduced in the shared code repository, and prevent issues from going out to production.
Therefore the code reviews we are talking about:
- Avoid errors/bugs by acting as a safeguard.
- Occur within the flow of making changes to production.
In this blog post, we will not discuss other types of Code Reviews that are done outside of the normal development flow.
Most common: Asynchronous code reviews.
We can see that A's development flow is constantly interrupted to wait for the corresponding feedback for each code review. This way of working delays the release to production, increasing the time it takes to receive real feedback from customers.
Because each individual code review takes so long, there is an unconscious and natural tendency for developers to work in increasing larger increments. At least, this is what I found in many teams I have worked with.
It is a curious situation because, on the one hand, the industry says that working in small safe steps is a recommended practice. On the other hand, many companies use async reviews that tend to discourage them.
So the most common way of working looks like the following diagram:
Small PRs tend to generate a lot of churn, people commenting etc. while bloated PRs just sail through -- no one wants to touch them with a 10 foot pole so they just push the Approve button.— Alex Bunardzic, white non-colonizer (@alexbunardzic) July 21, 2021
The problem are not branches or PRs per se, but the async, and thus delayed code review that chockes the flow of changes through the system.#continuouscodereview— Dragan Stepanović (@d_stepanovic) August 4, 2021
Is there a better way?Fortunately, there are synchronous code reviews and continuous code reviews.
Synchronous, high priority code reviewsThe first step is to give the highest priority to code reviews and to do them immediately and synchronously between the person who developed the increment and the person in charge of doing the review.
This way of working reduces the total lead time of each increment and encourages working in small increments.
As a side effect, the code reviews should be more straightforward because the developer themself explains them and can express in detail why they have taken each of the decisions.
Pairing/Ensemble programming: Continuous Code Review
Pair programming: "All code to be sent into production is created by two people working together at a single computer. Pair programming increases software quality without impacting time to deliver. It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality. With increased quality comes big savings later in the project.". http://www.extremeprogramming.org/rules/pair.html
The industry vision, my personal vision
- Trunk Based Development (https://cloud.google.com/architecture/devops/devops-tech-trunk-based-development), where they talk about working in small batches with synchronous code reviews. (See: https://twitter.com/jezhumble/status/1415908836439773185)
- Continuous Integration (https://cloud.google.com/architecture/devops/devops-tech-continuous-integration) that implies integrate any code change in the main branch of code at least daily (https://services.google.com/fh/files/misc/state-of-devops-2015.pdf#page=20). In this context, continuous and synchronous code reviews enormously facilitate the introduction of this practice.