In professional coding environments, it is common for us to have systems in place to check our work and verify that code written by one developer gets approved by others on the team. Review systems are a great way to ensure consistency and also raise flags and questions on better ways to streamline the work.
At a high level, this seems very straightforward — of course a team should be double checking work before releasing code! However, during times of tight timelines and pushes to do work fast, the temptation to skim over code reviews and merge without giving detailed thought can take over in order to save time.
There are obvious consequences to skipping over work-checking, but there are even more benefits that your team might be missing out if the code review is made a low priority.
Difficulty tracking down bug sources
Bugs happen. While every organization and team would like to think that they have golden code, it is inevitable that at some point, some piece may need to be changed or iterated on due to mistakes or even changes to dependencies. However, when code reviews are skipped, the ability to track down when and where a bug was introduced could potentially become more difficult.
In most cases, the team uses a form of source control, which helps track down sources. However, it becomes much easier to figure these things out when more than one person on the team has an idea of what pieces of code were touched, when, and by which team members. The most efficient way to do this is by consistently having peer code reviews before each pull request is merged.
Loss of consistency in code
For larger teams, having a consistent method or style of code is desirable. Following a convention can help streamline the way code is written, and make it easy to collaborate with other developers, and even other teams within the organization. When code reviews are skipped, it becomes easier for code to creep in that does not follow a specific style guide or method, or even duplicates something that is already there. This can cause issues down the road when methods are changed, or new developers take on work that results in a steeper learning curve than is expected.
Missing out on learning and growth opportunities
One major benefit of consistently having members of your team review other’s code is the amazing learning opportunity it brings. This goes both ways on the code review.
On one hand, the developer being reviewed can learn new techniques from their peers and also pick up good habits by having issues in their style, logic, and overall code pointed out to them with actionable solutions. On the other hand, reviewing someone else’s code can help open up new solutions that hadn’t been considered before, and enables a more collaborative effort to own the codebase, not just specific pieces of it.
Skipping code reviews can actually end up costing your team time
In some cases, skipping the code review will cost you more time than it will save. Let’s consider the most obvious issue with ignoring the code review process. Even the best developers can miss things in their code and make mistakes. When these issues fly under the radar and make it into production level code, or a developer has built code under the wrong assumptions, this can actually cost the team time. The team will then have to go back, find the issue, and possibly rewrite sections of code in order to fix the assumption. As this Atlassian points, out, there are other reason why poor reviewing can cost time.
In conclusion, while forgoing a code review or moving away from the process can be tempting sometimes, its most likely not going to save you time, or make your code better. Even a quick code review process for each pull request can help your team stay on the same page and stay accountable for their work. If you have additional thoughts on code reviews, or even some comments on when you don’t think a code review is necessary, We would love to hear your thoughts in the comment section below!