Today’s digital landscape, with its constant transformation, makes it imperative for software developers to consistently up their game and streamline their processes to maintain accuracy and efficiency. A code review is critical in every team’s effort to self-organize and continuously learn.

What is a code review?

A code review (or a peer code review) is a quality assurance activity where peer reviewers check a program by viewing the source code after implementation or as in interruption of implementation. In simpler terms a code review is when you get your colleagues to look over a code you’ve written to look for errors, areas for improvement, and overall consistency with system requirements. This also works vice versa — you review their work. This is an integral part of software development.

Though the main goal of a code review is to look for any defects, there are other benefits that come from performing code reviews:

• Knowledge transfer – code review is an opportunity for developers to exchange tips and knowledge about solution approach, the actual code base, etc.
• Quality control – writing the source code might preclude you from seeing errors as you are close to the process. Having a fresh set of unbiased eyes could flush out defects, point out deviations from uniformity, and make sure that you are well within the quality guidelines.
• Teamwork – this is often overlooked as a benefit of code reviews. Reviewing a colleague’s work will foster a sense of camaraderie that stems from the exchange of knowledge and the shared experience of a code review. It brings about the feeling of being in the same boat and having a collective sense of responsibility for the codes being written.

Different Types of Code Review Process

Formal Inspection

A formal inspection is a heavy process review that involves the participants meeting in one room, printouts of the code in hand (or in a laptop hooked to a projector) and reviewing parts of the source code. There are usually three to six people involved with one person acting as a moderator.

The rest of the team is assigned roles that they need to fulfil during the inspection. The roles would include a “reader,” someone who reads the code solely for the purpose of comprehending what it is and not critiquing it. Often, when the reader presents his understanding to the inspection team, the author can already pick out the defects in the code they wrote. Especially if how the reader understands the source code is different from how the author intended it to be.

In a formal inspection, when defects are detected, they are recorded in great detail. They capture the location of the defect in the code, the severity, type (data usage, documentation error, etc.), and the phase (did it not meet the requirements, was it an error on the developer end or was it a design error?). These errors are then usually plugged into a database for metrics and comparison.

Lightweight (Informal) Code Reviews

From the name itself, the reviews found under this type are not as heavy as those in a formal review, though they are equally effective. Lightweight reviews are often part of the whole software development process. Some of the most common ones are listed below:

• Over the shoulder review. This review involves having your reviewer looking over the author’s shoulder as the author walks the reviewer through the code. This is the most common review employed by most companies.
• Email pass-around. This type of lightweight review is preferred by open-source projects. The process is exactly what it sounds like. The author packages up his code and sends them to the reviewers through email. Then, the reviewers check the code, find defects or areas for improvement, and then send their feedback to the author for deliberation.
• Tool assisted review. This type of review needs specialized tools throughout the process — from files collection, deliberation, to collecting metrics.

Why is it important?

Code reviews take time, especially if you do a formal code review, but the payoff is definitely worth the time and effort put into the review process.

Code review and quality assurance

This is perhaps the most logical reason to have a code review. It ensures better quality. When you are the code’s author, you have probably read and re-read your code countless times and your eyes have become so familiar with it that they no longer see errors. Much like a novelist needs an editor, a code author needs reviewers.

Code reviews shine a light on pieces of code that could compromise security or performance. This could unearth runtime errors and any other pieces of code that might cause a bottleneck somewhere down the line.

Code review makes better developers

There is knowledge transfer happening whenever a code review is done. Older, more experienced engineers could mentor newer authors about writing clean code. This is a chance for peers to exchange information about current guidelines, tips on how to arrive at a solution, and overall learn from other people’s expertise and experience.

Code review saves time

It might seem counterintuitive at first because code reviews DO take time. However, the defects and other errors caught during the code review will make for an easier quality assurance testing phase. QA testers don’t just need to test quality, they also need to pinpoint the factors that led to poor quality results. If it fails quality testing, it will involve rework, more time spent looking for errors, rewriting code, and then putting it through QA testing again. If a code review is done before it reaches the testing phase, persistent errors and reworks can be avoided.

Code review for compliance and maintainability

We all need to adhere to quality assurance guidelines. Having a bunch of experts look at a written code assures that at least one of them will catch a QA violation.

Code review also ensures the easy maintainability of a certain software. Software creation and maintenance is an involved and expensive endeavor. A code that is simple and well-written will be easier to maintain even if the author developer leaves and another one takes their place.

Conclusion

Code reviews may take a lot of time and it may involve more people, but the benefits of having code reviews as part of your process — knowledge transfers, quality assurance, compliance, and maintainability are worth the extra time it takes. The time you save by not needing any significant rework and the cost you save by avoiding defects are a good exchange for the effort expended to do a code review.