For many companies, code review is an important part of the developer’s daily work. Through code review, problems in the project can be discovered early, communication and communication between colleagues can be promoted, and a spark of wisdom can be generated in the discussion. But to successfully implement code review is not an easy task. Why do code review, when to do it, and how to do it are three important issues before us. For these three questions, developer Lisa Tjapkes wrote about his own experience and lessons.

In my recent project experience, we conducted extensive and formal code reviews. This process greatly improves the code quality of the project, reduces the waiting time for new feature development in the project, and promotes the dissemination and sharing of knowledge across the team. I also found that code review does not delay project development time, but rather increases developer productivity.

The benefits of code review

  We’ve found that code review brings many benefits to all phases of the project:

  • Code review at the beginning of the project will help us make better use of the code base we have built, because if we haven’t used some existing code, we can get feedback from current developers.
  • As the project progresses, we will add new developers to the team from time to time, and code review can greatly reduce the familiarization time of these newcomers. In particular, we can allow newcomers to develop new features with confidence, because we can review the code before the merge and provide valuable feedback on any code they write.
  • For our distributed team, code review is more practical. Team collaboration can be a great help in building a collaborative environment. We can come up with ideas, discuss them, and then develop. Although we will lose something because we are not in the same place, we can get the benefits through in-depth discussions during the code review process.

Efficient code review techniques

  Code review methods can lead to project delays if not handled properly. Using the right tools and techniques can prevent a lot of time was wasted on review and improve the quality of your code.

Use feature branch

  Needless to say, the benefits of this practice, but it provides more specific benefits for code review. The feature branch means that you can isolate the code you need to review to only be related to a specific feature. The feature branch also takes into account fast context switching when the code is ready for review. When the current code is reviewed, you can switch to the new feature and switch back quickly if you need to discuss feedback on the review feature.

Isolate the review as a minor modification

  Small revisions will have less review time than larger revisions. When reviewing large changes, you not only have to look at a lot of lines of code, but also a large amount of dependent code to really understand. The result is that there is no linear relationship between the time spent reviewing the code and the amount of code being modified. Isolating the code to be reviewed into small modifications can reduce the mental burden of 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 need to include difference comparisons, be able to modify comments line by line, and notify everyone when the code being reviewed changes. My team uses GitHub to manage project code and uses GitHub’s pull request feature to manage code reviews.

Checklist

  It may not be necessary to use something that is very complicated or too structured. If there are some problems suddenly, it may be a good idea to use the checklist.

Constructive input

  It’s too meaningless to say something like “add more comments” and it doesn’t help much. If an interface has no comments, there may be special documentation for explanation. If you find something unreasonable, you should make it clear that you can improve the design or whether there is a logical error.

  Focus on the true understanding of the code’s behavior and ensure that the code is quickly understood when others need to maintain it.

Everyone participates

  Even the most experienced architects or star developers make mistakes. Therefore, it is best for everyone to participate in the process of code review. In particular, this is a great learning opportunity for many junior developers or developers who are new to the project.

Have a review process

  In the beginning, our project did not have a formal review process. We just open a pull request, wait for someone to review, and finally someone will merge and modify. This way of working is very inefficient, and sometimes no one reviews a pull request for several days. Sometimes someone else merges the request before giving feedback. In addition, some developers review a lot more code than others. All in all, no process leads to our inefficiency.

  Finally, we realized this and created a formal structure to guide how to conduct code reviews, which speeded up the review. A review process should at least cover the following points:

  • How to assign review tasks to different people
  • Expect the latest time for the reviewer to give feedback
  • How to identify that a review has been completed
  • Who is responsible for merging the code that has been reviewed

Should I conduct code review in my project?

  I think code review is a good thing for many projects, but it is not a universal solution. Code review is suitable for the following projects:

  • At least 5 developers
  • When adding new developers to the team
  • The team is distributed
  • The project has a variety of different components that are developed by different teams.
  • While still in the stage of setting up conventions and best practices for the code base
  • Some members of the team are not familiar with the technology stack currently in use.

  Instead, code review does not add more added value to the project in the following situations:

  • Handling maintenance code instead of adding new features
  • The team is small and intimate