Do We Need a Code Review?

Code review is one of the best practices commonly used in software development. Many developers include it in their development workflows. However, code review has some traits which many consider as disadvantages. Let us see these traits and find a way to deal with them.

Not So Good

When some developer (author) writes code, he/she cannot always evaluate it and find all the issues. So, the second person should take this code and check it. This process of evaluation by another software developer (reviewer) is called code review or peer review. And what is wrong with that?

Well, the benefits of code review are clear — better code quality, fewer issues, proper testing, and proper team communication. But this approach has its drawbacks, the biggest of which is additional time. Depending on the project and team, code review makes take from 20% to 70% additional time on the top of implementation time. And it is evident that project managers are not happy about this time spent without gaining anything except for the virtual “code quality. “

The following chapters describe different approaches to deal with this situation.

On Second Thought

The person who has ever switched from a project without code review to a project with it can immediately tell the difference. Fewer issues, smaller risks, better-organized flow, satisfied customer — these are consequences of a proper code review. You may estimate how much all these benefits costs — and it is usually more than a cost of time spent on code review.

If these arguments are not substantial enough for you, then you may think about code review as an investment. And not only investment into a product, but also human resources — software developers. Code review not only guarantees high quality of written code but also ensures experience and knowledge sharing between the team members. So the team may spend some time participating in the external training, or spent the same time improving the product — and still gaining knowledge and experience!

But even with this knowledge, there are still some people who would like to avoid spending time on code review at all costs. What are the alternatives then?

Possible Alternatives

The primary purpose of code review is quality assurance. So, in other words, we need to do quality assurance without code review and without spending extra time.

The very first thing that comes to mind is pair programming. One developer (driver) is writing code while the other developer (observer) doing review in real-time, and then they switch the roles. The apparent advantage of this approach is the simplified development workflow as there is no need for a code review phase at all. The disadvantage is also clear — you need two developers to implement a feature.

Another approach is to rely on automated tests entirely. If your team is using test-driven development, you have automated code style checks, excellent automated acceptance scenarios (e.g., using behavior-driven development), and continuous integration to runs all the tests and scenarios — then you may indeed do not need a code review. Every possible mistake will be found on the testing stage. However, such a process is extremely hard to set up, so you may still use code review as a temporary quality control tool.

Finally you may rename code review to something else, or combine it with other phases. Developers still are going to review each other's code and find bugs, but you may simplify the development workflow and have the same quality of code. The disadvantage — time spent on all that is still the same.

All the code review recommendations mentioned above are best practices tested by many software development teams. One way or another, somebody has the test the implemented functionality, and it is only up to you to decide who has to do it. Just make sure that it is not your customer!