10 Experiences with efficient code review

Code Review is a commonly used tool in software development, and it is easier to identify problems that are more difficult to find than QA testing, and to help team members improve programming skills, unified programming style, and more.

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

Teams need to recognize that code reviews are designed to improve the ability of the entire team, rather than checking "checkpoints" for individual settings.

"A's code has a bug is discovered by B, so a ability is not good, b ability is better", this kind of trap is very easy to 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 their own mistakes and learn from others ' ideas. If the developer is conflicted or disgusted with the process, the goal will not be achieved.

2. Cautious use of the discovery rate of the problem in the review as an evaluation criterion

If problems are found in code review, this is a good thing for the discovery of the problem and should be encouraged. But for those who are found, we do not advocate the use of this method to punish. Bugs are inevitable in software development, and it's counterintuitive to be overly demanding. To make matters worse, code review has no value or significance if it causes participants to be afraid of taking responsibility and unwilling to point out problems in the review.

3. Control the number of code per review

According to a survey conducted by Smartbear in Cisco, the code for each 200-line-400-line review works best. Every time you try to review too much code, the ability to discover problems declines, and the specific proportions are shown in the following illustration:

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

4. Conduct a review with questions

In each code review, we ask the censor to use his or her own experience to think about the problems that might be encountered, and then examine the work to verify that the issues have been resolved. One trick is to start with a user-visible feature and assume a more complex usage scenario to verify that the usage scenario works correctly in code reading.

Using this technique, you can give the censor a sense of generation, real immersion into the code, and improve efficiency. We all know that martial arts fiction is not easy to doze, and reading professional books easy to doze off, because martial arts fiction is more likely to produce a sense of generation.

Some studies suggest setting goals each time, controlling the amount of code that is audited in a unit period. This method in our practice appears to be very mechanical and flow, not as good as the above method effect.

5. All problems 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 the problem exists and ensure the problem is solved

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

Sometimes, in order to be efficient, experienced censors tend to modify the code and even refactor all the code directly, but this is not conducive to increased team efficiency, and will increase the risk of introducing new bugs because of refactoring, which is usually discouraged.

6. Use code review to activate individual "initiative"

Even if the project is in a tight schedule, it is not possible to conduct a full code review, or at least some code review, then it is a good idea to extract some key parts.

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

7. Conduct code reviews in an informal, relaxed environment

As mentioned earlier, code review is a mental-intensive task. Participants need to do the work in a more relaxed environment. Therefore, we believe that code reviews in the form of meetings, as suggested in some practices, do not work well, not only because of the inefficiencies of lengthy meetings, but also because of the controversies and thinking that may arise at meetings that are not conducive to such complex tasks.

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

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

(1) Annotate the code to explain the reasons behind this change and to facilitate review by others.

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

(3) From the overall survey of the design, whether complete consideration of all scenarios. The design that is done prior to implementation, if there is an ill-conceived situation, can be well remedied at this stage.

In practice, we find that even if only the original author is doing code review, it can still improve the quality of the code.

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

A member should make a handy record when encoding, including commenting in the code, or recording a simple personal document, which has several benefits:

(1) Avoid omission. Any issues that will be taken into account in the coding process are recorded and the issues are checked again during the review phase to confirm the resolution.

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

(3) The rate of occurrence of such problems is significantly reduced after repeated notes are recorded and similar problems are found in the review.

10. Use good tools for lightweight code review

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

Each team member develops functions independently, and then submits the code to the censor using the pull request form. Reviewers can easily read the code on the Web page, add comments, and so on, and then the original author will automatically receive e-mail reminders to discuss the comments.

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

Original link: http://www.html5cn.org/article-4001-1.html