10 experiences of efficient code review

Code Review is a common tool in software development, and it is easier to find and structure and time-related problems than QA testing, and 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 recognize that code reviews are designed to improve the ability of the entire team, rather than checking "levels" for individual settings.

"A's code has a bug found by B, so a ability is not good, b ability is better", this kind of traps can easily be spread to affect the collaboration within the team, so need to avoid.

In addition, the code review itself can improve the developer's ability to learn from the mistakes they have made and learn from the others ' ideas. If the developer has a conflict or aversion to this process, the goal will not be reached.

　　2. Prudent use of the detection rate as an evaluation criterion for the issue under review

If a problem is found in code review, it is a good thing for the person who found the problem and should be encouraged. But for those who are found, we do not advocate the use of this method of punishment. Bugs are unavoidable in software development, and excessive demanding is inherently counterintuitive. Worse, the code review has no value and meaning if the participants are afraid of taking responsibility and are reluctant to point out the issue in the review.

　　3. Control the number of codes per review

According to a survey conducted by Smartbear in Cisco, the code for each review of 200 lines-400 lines works best. Each time you try to review too much code, the ability to find the problem drops, as shown in the specific proportional relationship:

In practice, we find that the optimal code review varies with the development platform and the language of development. But it is really necessary to limit the amount of each review because it is a high-intensity brain-intensive activity. For a long time, the code in the censor's eyes is just letters, without any logical connection, naturally there will not be too much output.

　　4. Carry out a review with questions

In each code review, we asked reviewers to use their experience to think about the problems they might encounter and then verify that they were resolved by reviewing the work. One trick is to verify that the usage scenario works correctly in code reading, starting with the user-visible functionality and assuming a more complex usage scenario.

Using this technique, you can give the reviewer a sense of being in, and actually immerse yourself in the code to improve efficiency. We all know that the martial arts fiction is not easy to doze off, while reading professional books easy to doze, the reason is that the martial arts fiction more prone to generation sense.

Some studies suggest that each goal should be set to control the amount of code audited within a unit of time. This method in our practice appears to be very mechanical and process, as the above method effect is good.

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

If a problem is found in the review, it must be confirmed by the original author.

This is done for two purposes:

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

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

Sometimes, for the sake of efficiency, experienced reviewers are more inclined to modify the code directly or even refactor all the code, but this is not conducive to improving team efficiency, and will increase the chances of refactoring introducing new bugs, which we usually don't encourage.

　　6. Use code review to activate individual "activism"

It's a good idea to extract some of the key parts, even if the project schedule is tight and you can't fully review the code, or at least part of the code.

The logic behind this is that software development is very creative work, and developers have strong self-drive and self-fulfilling requirements. Letting the developer know that any code he writes could be read and examined by others, prompting the developer to focus, especially to avoid submitting code that is bad quality or even low-level errors to peer review. Open source software is also a good use of this mindset to improve code quality.

　　7. Code review in an informal, relaxed environment

As mentioned earlier, code review is a brain-intensive task. Participants need to do the work in a more relaxed environment. Therefore, we think that it is not good to conduct a review of the code in the form of a conference, as suggested in some practices, not only because long meetings are inefficient, but also because the controversies and reflections that may arise at meetings are not conducive to such complex work.

　　8. Self-Review before submitting the code, add a description of the code

All team members must conduct a review before submitting the code to other members for review. In addition to checking the correctness of the code, this self-correcting form of review can also be done as follows:

(1) Add comments to the code to explain the reasons behind this modification and facilitate review by others.

(2) Correcting the coding style, especially the naming of some key data structures and methods to improve the readability of the code.

(3) from the overall review of the design, whether the complete consideration of all scenarios. This stage can be well remedied if there are poorly thought-out scenarios for the design done before the implementation.

In practice, we have found that even if only the original author is reviewing the code, it can still improve the quality of the code well.

　　9. Record notes in the implementation can improve the problem detection rate very well

There are several advantages to having a member do a handy recording when coding, including commenting in the code, or documenting a simple personal document:

(1) Avoid omissions. Any issues that will be taken into account during the encoding are documented and re-examined during the review phase to confirm the resolution.

(2) According to the study, everyone is used to making some repetitive mistakes. This type of problem is recorded in the code and can be used as a basis for inspection at the time of the review.

(3) The incidence of such problems will be significantly reduced after repeated notes and similar problems found in the review

　　10. Use good tools for lightweight code review

"工欲善其事, its prerequisite". We are using the code hosting services provided by BitBucket.

Each team member develops the functionality independently and then submits the code to the reviewer in the form of pull request. Reviewers can easily read the code on the page, add comments, and so on, and the original author will automatically receive an email alert to discuss the comments.

Even if the team members are distributed in far apart, the tools provided by BitBucket can be used to review the code very well.

"Turn from"http://www.williamlong.info/archives/3272.html

10 experiences of efficient code review