Software developers routinely perform code review in order to maintain and improve overall code quality and product quality. Like any other process code review has a set of best practices.

Here’s a list of best practices you can follow for your projects:

Review each change in the source code by at least one team member

For complex software products and SaaS even changing a single line of code in a critical component or module can accidentally break the whole application. For example consider any code changes in the payments checkout module. Setup the CI environment such that it’s not possible to push changes bypassing the review flow and approvals.

Annotate the source code before code review

Software developers should add clear comments and annotate code before the review occurs. The comments and annotations guide the reviewer through the code structure, the changes, letting them know which files to look and the reason for code modification. Annotations should aid the process and provide reviewer with more depth in context. As an added benefit, the annotations even help the development team to find any related files, code snippets etc. through the product development.

Send less than 500 lines of code for code review

Reviewer can review smaller requests more effectively and efficiently. Plan and split large functionalities into several smaller tasks so that fewer lines of code can be submitted for code review. If it’s not doable, then developers can create draft pull requests and regularly commit changes. It will allow peers to review changes regularly during feature development.

Ideally, a review of 200-400 LOC should not take more than 60 to 90 minutes. Typically such sessions can yield 70-90% defect discovery. So, for every 10 defects that exist in the code, a properly conducted review would find seven to nine defects.

Set goals and capture metrics

Before implementing a process, the team should decide on how to measure the effectiveness of code review. The goals should be quantifiable for improving code quality and also qualitative to improve the overall software product or customer experience of the SaaS.

An example of quantifiable goal is to “reduce the number of defects injected in next feature development by half”.

Capturing metrics for the code review can also provide a measurable report of the progress and improvement in code quality. Some key metrics^[1] which can be tracked are:

• Inspection rate: the speed at which a code review is performed
• Defect rate: the number of bugs found every hour of code review
• Defect density: the average number of bugs found per line of code

A metrics-driven review helps in getting a better sense of how effective the code review is and adding value to the code quality.

Reviewer is also responsible for code

The reviewer is equally responsible for the code quality, not just the developer. The name of reviewer can be added to commit message or to Trello ticket for reference.

Log the time spent on code review

Usually an effective code review is takes at least an hour. Taking it into consideration both the developer and reviewer should be able to allocate and log time spent on review. Ideally, time should be allocated for code review while planning the sprint and should be followed through. Code review is just as important as code development and should not be an after thought in product development planning.

Reviewer should be made aware of acceptance criteria

One of the key aspects of code review is to understand whether the code performs and fulfills the requirements. So ideally the before beginning the process the reviewer should be made aware of the acceptance criteria of the functionalities.

Code review checklist is used by the reviewer

The reviewer should create a handy checklist before starting the review. It can have questions that ultimately help the reviewer achieve the goal of review.

The checklist should answers the question “What I need to look at during a review?”. The checklist can include other general considerations like “Does the new code cover any dependencies?”, “Are there any duplicates?”, “What is the naming nomenclature or folder structure?” and some project-specific stuff if needed.

The software developer should get a comprehensive feedback from reviewer

A reviewer shouldn’t just say “Refactor the code!” or “Split the components further into two parts” but need to explain the reasoning for the requested changes.

Code quality ensures quality service

At V2STech we trust and incorporate code review for product development and SaaS development. It allows us to maintain and improve our code quality and offer quality service with each delivery. It fosters positive approach in our developers to collaborate better, take ownership of product quality and deliver a better experience for our customers.