Internet Development: 10 experiences in efficient code review

 

Code Review is a commonly used method in software development. Compared with QA testing, Code Review is easier to discover problems that are difficult to discover, such as architecture and timing, it can also help team members improve their programming skills and unify the programming style.

　1. Code review requires the team to have a good culture

The team needs to realize that code review aims to improve the entire team's capabilities, rather than checking the "checkpoints" set for individual users ".

"A's code has A bug discovered by B, so A's ability is not good, and B's ability is better." This kind of trap is easy to spread and affects internal collaboration of the team, so we need to avoid it.

In addition, code review can improve the developer's ability to learn from their mistakes and others' ideas. If developers are in conflict with or dislike this process, this goal will not be achieved.

　　2. Exercise caution when using the issue discovery rate during review as the evaluation standard

　　

 

If a problem is found during code review, this is a good thing for the problem discoverer and should be encouraged. But for the discoverer, we do not advocate using this method for punishment. Bugs are inevitable in software development, and excessive demand is against common sense. Even worse, code reviews do not have any value or significance if they are unwilling to refer to problems during the review if they cause them to be held accountable.

　3. Control the number of codes for each review

According to a smartbear survey at Cisco, the best performance is to review 200-400 lines of code each time. Each time you try to review too much code, the ability to identify problems will decrease, as shown in the specific proportional relationship:

　　

 

In practice, we found that the optimal amount of code review varies with the development platform and language. However, limiting the number of reviews per time is indeed necessary because this process is a highly intensive mental activity. For a long time, the Code is only a letter in the eyes of the examiner, and there is no logical connection. Naturally, there will not be much output.

　　4. Review with questions

In each code review, we require reviewers to use their own experience to first think about possible problems, and then verify whether these problems have been resolved through review. One trick is to start from the user's visible functions and assume that a complicated application scenario can be used to verify whether the Application Scenario works correctly in code reading.

By using this technique, reviewers can have a sense of substitution and truly immerse themselves in the code to improve efficiency. As we all know, watching martial arts novels is not easy to sleep, but reading professional books is easy to sleep, because martial arts novels are more likely to generate a sense of substitution.

Some research suggests that you set a goal each time to control the number of codes audited per unit time. This method is very mechanical and procedural in our practice, and is not as effective as the above method.

　5. All problems and modifications must be confirmed by the original author.

If issues are identified during the review, they must be confirmed by the original author.

This has two purposes:

(1) Confirm that the problem exists and ensure that the problem is resolved

(2) Let the original author understand the problems and deficiencies and help them grow

Sometimes, for efficiency purposes, experienced reviewers prefer to directly modify the code or refactor all the code, but this is not conducive to improving the team's efficiency and will increase the chance of introducing new bugs due to refactoring, we usually do not encourage you.

　6. Use code review to activate individual "initiative"

Even if the project progress is relatively tight and the Code cannot be fully reviewed, at least some code should be reviewed. It is a good way to extract some key parts immediately.

The logic behind it is that software development is very creative, and developers all have strong self-drive and self-realization requirements. Let developers know that any code they write may be read and reviewed by others, which can help developers concentrate, especially to avoid poor quality, even code with low-level errors is submitted for peer review. Open-source software also makes good use of this mentality to improve code quality.

　　7. Perform code reviews in informal and easy Environments

As mentioned above, code review is a mental-intensive task. Participants need to perform the work in a relatively easy environment. Therefore, we believe that, as recommended in some practices, code review in the form of meetings is not effective, not only because long meetings are easy to make efficiency low, even more, the possible disputes and reflections at meetings are not conducive to such complicated work.

　8. perform self-review before submitting the code and add instructions on the code.

All team members must perform a review before submitting code to other Members for review. In addition to checking the code correctness, this self-correcting form review can also complete the following work:

(1) Add comments to the Code to describe the reasons behind this change and facilitate the review by others.

(2) Revise the encoding style, especially the naming of some key data structures and methods to improve the readability of the Code.

(3) Check the overall design and whether all the scenarios are fully considered. If the design we have done before implementation is not considered weekly, this stage can be well remedied.

In practice, we found that even if only the original author reviews the code, it can still improve the code quality.

　　9. Recording notes in implementation can greatly improve the problem discovery rate

When coding, members should easily record the code, including using comments in the Code, or recording simple personal documents. There are several advantages to doing so:

(1) avoid omissions. Any issues that are taken into account are recorded during coding and are re-checked during the review phase to confirm that these issues are addressed.

(2) According to the study, everyone is used to making repetitive mistakes. Such issues are documented and can be used as a basis for inspection during review.

(3) After repeated notes are recorded and similar problems are found during review, the occurrence rate of such problems will decrease significantly

　10. Use good tools for lightweight code reviews

"To do well, you must first sharpen your tools ". We use the code hosting service provided by bitbucket.

Each team member develops features independently and then submits the code to the examiner in the form of a Pull Request. The reviewer can easily read the code and add comments on the webpage. Then, the original author will automatically receive an email reminder to discuss the comments for review.

Even if the team members are distributed across the north and south of the sky, code reviews can be well performed using tools provided by bitbucket.

Source: nut cloud (http://jianguoyun.com /).