Code reviews: useful or a waste of time?

One of the most important skills for a developer is the ability to write clean code that is maintainable and error-free. No matter how skilled you are, it’s always possible that you’ll overlook certain bugs or potential problems. This is where the process of code review comes into play.

Code reviews have become a standard part of the software development process in many companies. Their purpose is to review code by teammates before it gets committed to a source code repository, helping to catch potential bugs, ensure adherence to coding standards, and share knowledge among team members.

Some developers appreciate code reviews, while others dislike them. While some argue they’re necessary, others question their effectiveness, calling them time-consuming and redundant. With the benefits widely debated, we examine both sides of the argument: Are code reviews truly useful or just a waste of time?

Read also: How to Do Effective Code Reviews: Tips and Tricks.

What is a code review?

Code review is the process of checking code written by one or more developers before it is merged into a common source code repository. It is a systematic line-by-line review of source code by one or more people to find and correct errors, improve quality and ensure compliance with coding standards. It typically involves developers reviewing code changes made by their peers, providing feedback, suggesting improvements and identifying potential problems. Code reviews can be conducted using a variety of methods, such as pair programming, email, face-to-face or online meetings, or using specialized tools that facilitate asynchronous reviews.

Code review process

A code review typically examines various aspects of the code to ensure its quality and correctness. We provide a list of some of the key metrics that can be checked during the code review process:

Functionality: Verifies the code performs required operations correctly. The code is reviewed to ensure that it meets the requirements and ensures the correct processing of data and inputs.

Efficiency and optimization: Code efficiency is checked and opportunities for optimization are sought. This may include changing algorithms, eliminating redundancy, or improving the performance of critical parts of the code.

Security: The code is assessed for compliance with security standards and policies. This includes preventing potential security vulnerabilities such as SQL injection, cross-site scripting (XSS) or unauthorized access.

Architecture and design patterns: Analyzes whether the code conforms to the design patterns and architectural principles used in the project. This includes checking that the code follows standard design rules for classes, modules and layers.

Readability: Measures how easy it is for other developers to read and understand the code. This aspect includes important factors such as the use of understandable variables, correct and descriptive function names, and commenting out the less understandable parts of the code.

Coding style and conventions: Checks that the code follows the specified coding conventions and styles that are defined for the project or programming language. This aspect includes code formatting, the use of spaces, indentation, etc.

Testing: Checks that the code has been properly tested, and that tests have been written that cover all critical aspects of its functionality. This also includes checking that the new code hasn’t broken existing tests and that it doesn’t add new test scenarios.

Documentation: Assesses whether the code is adequately documented to make it easy for other developers to understand and use. This includes code comments, documentation of the new API, and user guides.

Code review types

Let’s now look at the different types of code checks used in companies.

In person (or screen sharing via MS Teams)

This method is fairly easy and convenient for most developers, and the developer gets feedback fairly quickly. When your code is ready, you find an experienced team member, make an appointment and go through the code you’re committing to the repository together, either in person or online. This type of code review is suitable for smaller changes, as the reviewer does not have a lot of time to look at the code.

E-mail threads

It solves the problem of scheduling code reviews. Once a particular piece of code is ready for review, the file (or a hyperlink to it) is emailed to the appropriate colleague(s) so that everyone can look at it as soon as their work schedule allows. While this approach can certainly be more flexible and adaptable than more traditional techniques, such as a meeting of people dedicated to code review, an email thread of suggestions and differing opinions on how to fix the code can quickly become bloated, and it may not be clear what has been fixed and what hasn’t.

Pair programming

Pair programming is an approach to software development in which (usually) two developers work together on the same code, collaborating and reviewing each other’s work. It’s a good way for senior developers to mentor junior colleagues and to incorporate code review directly into the programming process. However, this approach to code review loses the objectivity and unbiased approach of looking at and reviewing your own code. The main drawback is that it is more resource-intensive (especially in terms of people and time) than other methods.

Software tools

They combine the benefits of the previous approaches and address many of the limitations of the previous approaches mentioned above, providing a simpler and more efficient way to inspect code. Code review can be done directly in the browser, or these tools can be seamlessly integrated via plug-ins into various development environments or code management tools. They allow you to track peer comments and proposed fixes in a clear and consistent order (similar to tracking changes in MS Word), reviews are asynchronous (i.e. based on who is available and when), the author of the reviewed code receives notifications of new reviews. There is no need to find an experienced colleague and make an appointment to review the code, people work on their machines and have as much time as they need to assess the correctness of the code. In addition, software tools have various built-in metrics for static code analysis that can alert the reviewer to specific parts of the code that they should focus on in their review.

Code review benefits

Now let’s look at the arguments for and against code review. Let’s start with the arguments we can all probably agree on.

Two pairs of eyes see more than one

We developers sometimes overestimate how good our code is, and a second independent view can give us a different perspective on our code and allow us to look at it more objectively. The reviewer can give us valuable feedback on how readable and understandable our code is. We usually try to write code in such a way that when we come back to it after a while, we have no problem understanding how the code works and what it solves fairly quickly.

Knowledge sharing

Code reviews provide an excellent opportunity for team members to share knowledge and learn new things. Whether it’s different coding styles, techniques and best practices, or the use of new frameworks and libraries, I personally see this cross-fertilization as the greatest benefit of the code review process.

Early bug detection

One of the benefits of code review is that it is a form of bug detection, and catching bugs before the code is used in a production environment saves time and resources in the long run. However, the counter argument is that code should be functional and tested before it is reviewed.

Improved code quality

Another commonly cited benefit is improved code quality. By providing constructive feedback and suggestions for improvement, code reviews help to improve the overall quality of the source code. Reviewers can also identify areas for optimization, code refactoring or documentation improvement. However, these benefits tend to diminish with the experience of the developer, and an experienced developer will be able to identify these areas and take them into account when designing and implementing the solution.

Consistency of standards

Code reviews ensure consistency of standards and agreed coding practices across the team. This is true, but you can use various applications such as Sonar to check this automatically, eliminating the need to check it during the code review.

Code review drawbacks

We come to the arguments of the opponents of conducting code reviews.

Time-consuming and therefore expensive
And code reviews are rarely fun. So, especially under time pressure (which we all find ourselves under from time to time) or with a deadline looming, they are either not done at all, or at least occasionally skipped. This is especially true of previously reviewed code, which should be reviewed again whenever there’s a change to it.

In addition, code review can be time consuming, especially for large development teams or projects with large code bases. Thoroughly reviewing every line of code requires significant time and effort, which can slow down the development process.

Error-prone

Code reviews are prone to error because the reviewer is also just a human with varying degrees of experience, and in most cases is not a security expert. Despite the best efforts of the reviewer, some issues may slip through the code review. Human error, fatigue or lack of expertise in certain areas can lead to critical issues being missed, reducing the effectiveness of the code review process.

Two or more developers

You need at least two developers on the team who are familiar with the technology. The reviewer who reviews the code should ideally have the same or higher level of experience, because if a less experienced developer does a code review for a more experienced colleague, the whole code review process often loses its effectiveness.

Subjectivity issues

Code reviews can sometimes be subjective, with different reviewers having different opinions about the quality and style of the code. This subjectivity often leads to conflict or lengthy discussions within the team, which can delay the completion of the review and hinder productivity. If the feedback is too critical or incorrect, the author of the code being reviewed may feel demotivated. Similarly, if their code is not accepted into the repository after repeated reviews and incorporation of feedback. Software developers tend to love their own code more than anything else, and hate other developers’ code if it’s written in a way they don’t like. They are very sensitive about their code, and if someone points out that their code is bad, they associate it with them being bad developers.

Endless debates

Code reviews often lead to endless debates between developers. One developer can’t resist the temptation to prove to another that the way they write code is wrong. Developers tend to review code from their own perspective, and don’t like to consider other approaches as correct. We prefer to believe that our approaches are exactly right. This is because, as humans, we are too lazy and it is too painful to spend time and energy on solving a problem that has already been solved. Every developer wants to be acknowledged, so they present their arguments and use cases to convince the reviewer that their approach to solving the problem is better and more optimal. This leads developers into endless debates that ultimately hurt the company and its business.

Over-analysis

Another problem with code review is overthinking. Even if the code looks good at first glance, we subconsciously want to find a bug in it. We naturally feel good when we’re useful at something, and finding a bug in the code makes us feel useful. Paradoxically, if we give the improved (corrected) code back to the same reviewer to check again, they will find more things to improve. Furthermore, if we give the same code to another developer to check, they will find even more bugs.

Conclusion

We’ve presented different perspectives on pre-commit code reviews, and it’s clear that they have many advantages and disadvantages. Ultimately, we leave it to the reader to judge which of these outweigh the others. However, if the code review process is not set up properly, if it’s not given enough time, or if it’s done under time pressure, and if the reviewer doesn’t give constructive feedback to the programmer, it can seriously disrupt the team’s working atmosphere, and lead to non-constructive arguments about whose approach to problem solving is better. This is why it is important to start trusting yourself more and giving others the freedom to make decisions. At msg life Slovakia we also use code reviews, but only for new developers. In this way, they can learn a lot from more experienced colleagues and get into a productive working process more quickly.

If you’re a Java developer looking for a job, check out our employee benefits and respond to our job offers!

About the author

Jozef Wagner

Java Developer Senior

Viac ako 10 rokov programujem v Jave, momentálne pracujem v msg life Slovakia ako Java programátor senior a pomáham zákazníkom implementovať ich požiadavky do poistného softvéru Life Factory. Vo voľnom čase si rád oddýchnem v lese, prípadne si zahrám nejakú dobrú počítačovú hru.