CRs (Code Reviews) are the industry standard for keeping our code quality and sharing best practices between team members.
But if you think about what a CR is - it's someone reviewing your work after you're already done with it, and made a context-switch to a different task, and a different branch. Not a very effective way to ensure code quality.
Automation
Our coding practices evolved during the years. We tackle this problem by creating small commits, ensuring PRs (Pull Requests) are not getting stale and moving a large portion of code quality control to automated tools.
Code styling remarks are a thing of the past. We have linters and prettifiers, which means no more endless debates about code styling. Almost all errors are caught during coding time, and some are automatically fixed.
Most of these tasks already have automated tools that solve them.
Automated tests help verify the correctness of the code and regression.
We have automated checks that verify your code meets the performance metrics.
3rd party tools based on AI are starting to review our PRs automatically, and even create pull requests themselves, keeping industry standards, making patches to close security vulnerabilities, and updating open source packages.
What about code design and architecture?
If you think about it, if you've already written your code, wrote tests, and created a pull request - now it is probably a little too late for someone to suggest that you re-design your code.
Enter design reviews - ask for feedback before you write the code, and not after it.
The future of CRs - continuous review
Despite the current automation, we still do CRs. That's because we always want another pair of eyes on the code, and automation is still basic and can't understand the context of our code. So how will CRs change in the future?
In the future, more and more automation and collaboration will influence our coding environment. Thanks to AI, we will have tools that alert us in real-time if our code is duplicate or inefficient and if it conflicts with some other change that is being written by another developer. They will also suggest better names for our variables and methods and keep them consistent throughout the system.
The timespan between writing code and having it reviewed - by human and machine - will get shorter and shorter until it becomes continuous. The tools that shape our environment will become smarter, more real-time, and more collaborative.
The tools that allow us to collaborate will become more efficient and user friendly and will have a better and more intimate understanding of our work. These tools could, for example, allow us to review the history of comments and discussions around our code, who are the main contributors to it, ask for a review in real-time, and help us schedule the reviews to avoid bottlenecks and outdated branches.
So, unless AI can write code instead of us, and put us all out of work, I anticipate a bright future for developer productivity and happiness, and a future which lets us focus even more on what we like doing best - coding.
Top comments (7)
I pretty much agree with all the points you've made. But I wanted to elaborate on the opposite point as well. Code reviews still have good benefits. For example juniors can learn more by reviewing the code, the author may have missed some small things, other teams get visibility of the codebase so knowledge is shared, etc.
Also code reviews aren't done in a vacuum, they are a very small part of the entire software development process. If the software development process is lacking, then code reviews are strongly affected because doing a code review on a monolith is pretty useless, as you said. However if the software development process is good, this code reviews only provide the benefits.
The software development process can lack with things like:
TLDR: I agree with all the points you've made, however code reviews still have good benefits. The entire software development process has to be good for code reviews to be beneficial and not useless. The main problem is probably companies adding code reviews because of an agile checklist, rather than focusing on a good software development process overall.
The data disagrees with you. Code reviews are the single most effective bug-catching tool we have as developers. While it's a bit older (2004), Code Complete lays out some examples of this. Here's a Coding Horror blog entry about it:
blog.codinghorror.com/code-reviews...
Granted, we have a lot more tools now than we had then, but this kind of basic truth about software development rarely changes. You still need good design and teamwork (peer programming is great), but before you'd convince me not to make this a part of my development process, you'd need to show some proof that this has changed and code reviews are no longer effective. My experience on even recent reviews says they are still effective in real world usage.
Maybe you're dealing with a toxic environment where code reviews aren't done with a professional demeanor and everyone setting aside their egos. That's certainly a challenge. You need good facilitators on your team -- preferably other active developers -- to make sure everyone is respectful and that the code review process encourages that. That means having things like a team-agreed process -- e.g. an adopted style guide, run the linter before creating the review, comments on code must be backed up by (not just opinions), etc.
Thanks for the feedback!
Well, I admit the article's title is a bit provoking, but the message is not to stop reviewing each other's code, but how I think this will change in the future and allow us to collaborate more early on and more frequently. I definitely agree that in today's environment, every piece of code should be reviewed and that's our current practice.
As I lay out in the final paragraph - "The future of CRs - continuous review":
"Despite the current automation, we still do CRs. That's because we always want another pair of eyes on the code, and automation is still basic and can't understand the context of our code."
Code reviews are a waste of time. All the (wrong) design decision have been already made and it will be wasting everyone's time to start resolving those in the PR. The correct thing to do is collaborate early on before the pull request and the actual code review would be only a formality where we check that we don't have files we didn't intend to commit. Reasonable test coverage and static analysis should be relied on.
Another way of seeing it could be the: author of the code shares all valuable insights including documentation with the team so that new concepts get to know and the knowledge is spread immediately with the appearance in the code base. That is very valuable and helps to avoid knowledge silos amount a team.
Pair Programming instead ;)
Exactly what I thought!
We only do reviews when we don’t have a chance to implement a task as pair or even mob.
And no, there won’t be an AI that will replace a human to write or review code.
So yes, you shouldn’t do reviews, should implement in pair!