As we all know, Code Review is a very important link in the development process, but many companies or teams do not have this link. Today, the author discusses the value of Code Review and how to implement it based on his team.

1. The value of CR

Many teams don’t have Code Review, or think CR is a waste of time because they want to get the project online quickly. Or team members may lack a sense that CR is not valuable. Therefore, in order to promote the implementation of CR in the team, the most important point is to enhance team members’ recognition of CR.

Code Review is more dependent on the subjective initiative of team members. Only when team members recognize it, they will actively participate in this process and the value of CR can be maximized. If team members do not agree with CR, even if a mandatory CR process is set up, it is useless and may hinder the efficiency of the normal development process. So how do you get your team members to recognize the value of CR, of course, and then… How sweet!

1.1 Improve team code quality

Iterative upgrade with the scale enlargement of the team and project, the information transparency between the team will be more and more low, the maintainability of the project will be worse and worse, may cause the following a series of problems: the existing utils method, repetition of rolling code is too complex, lack of necessary annotation, difficult to maintain The directory structure is multifarious, a mess… A reasonable CR process can effectively control the quality of the code submitted each time, so that the maintainability of the project does not deteriorate with the release iteration and time, which is the primary purpose of CR. CR does not reduce development efficiency. For a single code submission, some people may think that CR may take time, but the time saved by effective CR for future generations to extend and maintain is far more than that.

1.2 Team technical communication

Reviewer and Reviewee could both gain a lot of knowledge and conduct technical exchanges during their participation in CR. It is helpful for new recruits to grow up quickly. When new recruits join the team (such as interns and school recruitment), they often need to lead the mentor for a period of time. Through the CR link, the mentor can directly understand the problems encountered in the development process of new recruits and make corresponding guidance. Through the CR process, team members can learn about other people’s businesses, not just their own. If a problem is found in the project, you can quickly locate the responsible person of the related service to rectify the problem. At the same time, if some team members quit, it can also reduce the maintenance difficulties caused by one person in charge of the business. Learn good code from others. Through the CR session, you can quickly get access to good code that your team members have been working on to solve some problem on the project, or use some API that you haven’t worked on before.

1.3 Uniform specifications of the project shall be guaranteed

Since we want to carry out CR, we should first make requirements for the specifications of the project, including coding style specifications, directory structure specifications, business specifications and so on. On the one hand, unified project specifications can ensure the code quality of the project, improve the quality and maintainability of the project; On the other hand, after everyone is familiar with the uniform specification, it can improve the efficiency of CR and save time.

2. Practice of Code Review

With regard to Code Review practices, considerations include how long CR takes, what form CR takes, when CR is performed, and so on.

2.1 Reserve the CR Time

First of all, we have to admit that CR takes a certain amount of time, so in the project schedule, we should not only consider the development, joint commissioning, testing, bug correction and other time, but also reserve CR time. This includes time spent in the Reviewer and Reviewee roles.

In addition, if the requirements are complex, it is better to communicate with team members about the design and results of the requirements in advance in order to avoid a large number of code modifications due to the CR process.

2.2 Form of CR

Most of the CR I’ve seen comes in two forms. One is to set up specific times, such as weekly, bi-monthly, etc., where the team members CR previous Merge requests together. The other option is to CR each Merge Request.

Personally, I prefer the latter. For the first periodic CR, the number of Merge Request is too large, so it is impossible to CR all The Mrs. If it is too costly to modify many of the previous Mrs After CR; And too many CRS at once can discourage team members. The second type of MR is relatively easier, and it can be considered that 2-3 people can be assigned to CR the MR on that day in shifts every day.

2.3 Timing of CR

The CR session should be set up before the test session. Because if the code is optimized after CR, although it is only code optimization in theory, it may affect the business logic, and if it is tested, it may affect the function points that have been tested.

Of course, it also depends on the situation. If you encounter urgent requirements or bug fixes, you can also test them first and then do CR accordingly.

3. What is required of team members

As mentioned earlier, it is important to strengthen team members’ identification with CR. As a participant in the CR process, he/she should also make corresponding requirements for team members according to his/her team characteristics. You can refer to our team.

3.1 Reviewer

Specify the level of review. Reviewer give corresponding code add comments, recommendations indicate review level, in the comments before with the [] to make identification, such as:

[request] XXXXXXX The code of this comment must be modified before it can be recommended to be modified through [advise] XXXXXXXX. However, if you do not modify the code of this comment, you can also use [question] XXXXXX to query the code of this comment, requiring further explanationCopy the code

State the reason for the comment. When commenting on the code, you should explain the reason clearly. If you have a better solution, you should comment on the corresponding solution to save reviewee’s revision time.

Equal and kind comments. In the process of review, the reviewer aims to improve the quality of the project code, rather than attacking others or questioning others’ ability. The reviewer should keep an equal and friendly tone.

Enjoy Code Review. Only by actively participating in CR and taking CR as a kind of enjoyment can the value of CR be maximized.

3.2 Reviewee

Focus on notes. For complex code, corresponding annotations should be written, and the background should also be clearly written in the commit to help reviewer understand and improve the efficiency of review.

Keep a positive attitude and accept others’ review. The review of your team members is not a criticism of you, but a help to improve you, so respect the review of others. If you feel that the review is incorrect, you can raise questions below and explain further.

After completing the revision of the corresponding review, please reply in time below to keep the information synchronized.

Source | urlify. Cn/eIzyya