DEV Community

Willian Corrêa
Willian Corrêa

Posted on

You don't need code reviews and PRs

PRs & Code reviews are a blocker and bottle-neck for value generation. Allow me to explain.

A Pull-request was a feature created to allow maintainers of an open source project to receive changes from unknown contributors. It solves a trust problem, allowing the maintainer to review code before rejecting or accepting changes.

Developers working together as part of a team don't have trust issues. Otherwise, it is a different problem in which PRs are not the solution. At best, the issues of a team are about quality and norms.

Automating testing and practices like TDD, CI, and CD can solve quality problems. Automated tests create faster feedback loops when compared to a PR waiting for review and the usual back & forth with comments.

Testing Driven Development helps developers to design their code better and enable testability. Tests are created to support the acceptance criteria in the stories. When they all pass, developers are free to merge the code and move to the next story.

Continuous Integration reduces the chances of merge conflicts. It supports the idea that any code in the main branch is working software ready to ship to production. Pipelines produce feedback and help to avoid regressions.

Continuous Delivery accelerates teams by avoiding branch strategies. Everything is merged into the main branch and continuos tested. Code is deployed into production often, and feature flags can be used to allow for tests in production or canary releases

Pair Programming or Mob Programming eliminates the need for code reviews. Code is reviewed as it is produced. Disagreements can be solved on the spot instead of async through comments. Knowledge is shared, avoiding silos.

Norms can be enforced with code static analysis tools as part of the pipeline and pre-commit hooks. Quality gates can be added to implement minimum thresholds. Developers can focus on value generation rather than reviewing code that is faulty in style but functionally correct

For regulated markets, compliance and regulations can be satisfied without code reviews in most cases with modern Quality practices.

Unless you are developing an open source project, you should seek to stop doing PRs & Code Reviews. It will accelerate time-to-market and help to improve the product further with more frequent customer feedback.

Top comments (7)

mcsee profile image
Maxi Contieri

Nice idea!

frankfont profile image
Frank Font

Willian, I would have agreed with you 100% about 3 years ago. What's changed for me since then is that I've been working with people that use PRs as an opportunity to peek at something they did not participate in and catch some fat-finger mistakes that are obvious to them, but perhaps not obvious to everyone else. The PR is not the quality guarantee -- it is just an additional proof-reading.

And code reviews, when done properly, are just a show-and-tell opportunity for a Q&A PR experience.

I am with you that using PRs and code reviews as a substitute for other good practices is a poor strategy. (Speed of trust is fastest way to quality completion -- here are my thoughts on that 8 principles of effective collaboration)

wgcorrea profile image
Willian Corrêa

Thanks for your comment Frank and nice article!

Code reviews can be done without PRs, as a team exercise. Pair Programming combined with TDD is enough to improve confidence to ship - at least that is my experience working with teams, even on high regulated markets where the requirements for evidence is higher.

kylereeman profile image

Well fine that automated tests eleminate quality issues. And what is when there is no test added that comes within a new features because there were no pr that claims about missing tests. PR is not about trust issue when I make a pr I am also more confident if at least one additional programmer who knows the business logic checks my code.

wgcorrea profile image
Willian Corrêa

Thanks for your comment Kyle; to clarify:

PR is a solution for a trust issue in the context of an open source project for the role of a maintainer. I even said explicitly that "Developers working together as part of a team don't have trust issues".

Following the principles I've listed, if you have TDD in place, the scenario where you don't have tests for new features does not exist. Also, working in pairs, gives the confidence that a second pair of eyes see your code before you merge.

moonseeker profile image
Moon Seeker

How often is / should pair programming happen?

wgcorrea profile image
Willian Corrêa

When working on user stories, you should work always in pairs - with proper pair rotation- or do mob programming. PoCs and spikes can be done individually, but the code produced should not be used for user stories but to inform team decisions.