The problem with the current most commonly accepted way of running code reviews using Pull Requests is that they have the nasty habit of blocking the flow of delivery. They introduce a cost of delay. Any delay reduces feedback. Consequently, it drives down quality.
The usual way to achieve fast efficient and effective Continuous Code Reviews without disrupting the flow of delivery is through Pair Programming or Team Programming. However, for various valid reasons, these are often a cultural stretch for many teams and organisations.
In 2012, a novice team practising trunk-based development put in place a fairly uncommon but efficient alternative to implementing continuous code reviews on mainline without ever blocking the flow of delivery. This team went from a bunch of rag-tags to becoming a reference team in the organisation, with auditors falling on the floor because of the amount of quality the team delivered.
TLDR; by Michael Lihs on LinkedIn
References:
- Optimizing the Software development process for continuous integration and flow of work, Martin Mortensen
- The Article: Non-Blocking Continuous Code Reviews, a Case Study, Thierry de Pauw
- I’ve found something better than PRs, Dave Farley’s video on the topic
- Out of the Crisis, Edwards Deming
- Code Complete, Steve McConnell
- Facts and Fallacies of Software Engineering, Robert Glass
- Accelerate, Nicole Forsgren, PhD et al.
- Joel on Software, Joel Spolsky
- What is the purpose of Code Reviews, Thierry de Pauw, a discussion on LinkedIn
- Gender bias in open source: Pull request acceptance of women versus men, C. Rainear at al., 2016
- From Async Code Reviews to Co-Creation Patterns, Dragan Stepanović
- I Hate Pull Requests, Pia Fåk Sunnanbo
- Problems with Pull Requests and How to Fix Them, Gregory Szorc
- On the Evilness of Feature Branching - But Compliance, Thierry de Pauw
- How to make sure tests are of quality, Thierry de Pauw, a discussion on LinkedIn