The Value of Code Review — Why, When, and How?

[[143001]]

For many companies, code review is an important part of developers' daily work. Through code review, problems in the project can be discovered early, communication and exchanges between colleagues can be promoted, and sparks of wisdom can be generated in discussions. However, it is not an easy task to successfully implement code review. Why do we need to conduct code review, when do we do it, and how do we do it? These are the three important questions before us. In response to these three questions, developer Lisa Tjapkes wrote an article about her own experiences and lessons.

In my recent project experience, we conducted extensive and formal code reviews. This process greatly improved the code quality of the project, reduced the waiting time for new feature development in the project, and promoted the dissemination and sharing of knowledge among the entire team. I also found that code reviews did not delay the development time of the project, but instead increased the productivity of developers.

Benefits of Code Review

We have found that code reviews bring many benefits to every stage of a project:

• Doing code reviews at the beginning of a project helps us work better with an established code base because we can get feedback from current developers if we haven't used some of the existing code.
• During the course of the project, we will occasionally add new developers to the team, and code review can greatly reduce the familiarization time for these newcomers. In particular, we can let new developers develop new features with confidence because we can review the code before merging and provide valuable feedback on any code they write.
• For our distributed team, code review is even more practical. Team collaboration helps a lot in building a collaborative environment where we can come up with ideas instantly, discuss them, and then develop them. Although we lose something by not being in the same location, we can gain the benefits of in-depth discussions during the code review process.

Tips for efficient code review

Code review can cause project delays if not handled properly. Using the right tools and techniques can prevent a lot of time being wasted on code review and improve the quality of the code.

Using feature branches

The benefits of this practice are self-explanatory, but it provides more specific benefits for code review. Feature branches mean that you can isolate the code that needs to be reviewed to only that which is relevant to a specific feature. Feature branches also allow for quick context switching when the code is ready for review. You can switch to a new feature while the current code is under review, and quickly switch back if you need to discuss feedback on the reviewed feature.

Isolate reviews into small changes

Small changes take less time to review than large changes. When reviewing large changes, you have to look at not only many lines of code, but also a lot of dependent code to truly understand them. As a result, the time spent reviewing the code is not linearly proportional to the amount of code modified. Isolating the code to be reviewed into small changes can reduce the mental burden on the reviewer and make the review process smoother.

Use tools designed specifically for code review

This may seem simple, but it is very important. Some important features include diffing, being able to annotate changes line by line, and notifying everyone when the reviewed code has changed. My team uses GitHub to manage project code, and we use GitHub's pull request feature to manage code reviews.

Checklist

It's probably not necessary to have something very complex or overly structured, but if something pops up, using a checklist might be a good idea.

Constructive input

Saying something like "add more comments" is meaningless and not very helpful. If an interface has no comments, there may be a dedicated document to explain it. If you find something unreasonable, you should point it out clearly and judge whether the design can be improved or whether there is a logical error.

Focus on truly understanding the behavior of your code, and making sure that others can quickly understand it when they need to maintain it.

Everyone participates

Even the most experienced architects or star developers make mistakes. Therefore, it is important that everyone can participate in the code review process. In particular, this is also a good learning opportunity for many junior developers or developers who have just joined the project.

There must be a review process

In the beginning, our project did not have a formal review process. We would just open a pull request, wait for someone to review it, and eventually someone would merge the changes. This way of working was very inefficient. Sometimes no one reviewed a pull request for days, and sometimes someone else merged the request before one person gave feedback. In addition, some developers reviewed a lot more code than others. In short, we had no process and our efficiency was extremely low.

***We recognized this and created a formal structure to guide how to conduct code reviews, which accelerated the efficiency of the review. A review process should at least cover the following points:

• How to assign review tasks to different people
• The latest time to expect feedback from reviewers
• How to mark a review as completed
• Who is responsible for merging reviewed code?

Should I do code reviews on my projects?

I think code review is a good thing for many projects, but it is not a one-size-fits-all solution. Code review is suitable for projects such as:

• At least 5 developers
• When adding new developers to the team
• Teams are distributed
• The project consists of various components, which are developed by different teams
• When you are still in the process of setting conventions and best practices for your code base
• When some members of the team are not familiar with the current technology stack

On the contrary, code review does not bring much added value to the project in the following situations:

• Dealing with maintaining code rather than adding new features
• The team is small and close-knit