The meaning of code review

Personally understood, code review has two functions:

1. Two people are always more thoughtful than one person, looking at the angle of the problem it is easier to find bugs or find simpler and more effective solutions. The so-called onlooker sees most is the truth.

2. Ideally everyone in the team is familiar with every part of the project, but when the project is large it is not realistic, and the code review at least allows everyone to know more about the business modules, and also to achieve the purpose of personnel interoperability.

At the same time code review should pay attention to the following issues:

1. The problem of the non-existent ability of the auditor and the audited person. Code reviews are designed to improve the ability of the entire team, rather than checking the "levels" for individual settings. "A's code has a bug found by B, so a ability is not good, b ability is better", this is a misunderstanding.

2. The code review itself can enhance the developer's ability to learn from the mistakes they have made, to learn from the other's ideas, and to learn from the review of the thinking process, from the reviewer's good design.

3. The code review does not involve a mechanism of rewards and punishments, even if there is also a reward or penalty for both the reviewer and the reviewer, i.e. both are responsible for the delivery at the same time.

Code review Take the way:

In practice, the closed-loop review recommended by our team members is well suited. Like a 4-person sub-team, review relationships for a-and B--and C--and D-to-a (b review a,c review b,d review c,a review D). Of course, to adapt to the ability of members to achieve effective insertion of high and low. So let Junior engineers review the code of the senior engineer is there a problem, can you find bugs? First of all, you can certainly find bugs, just how much and frequency of the problem; second, even if junior engineers can not find a senior engineer's bug, in the review of senior Engineer's code will also be able to learn good ideas and business knowledge, which is very meaningful, indirectly play the role of training.

Unit granularity and time issues for code review:

It is easier to implement review with future and task tasks as units, and large-scale review can be initiated separately during major improvements. It is also a good practice to combine review into a task workflow. Such as: Start-to-design--and code review---test--and product confirmation--end.

The time of a review unit should be controlled in 10-20 minutes. If this time is exceeded, there are several possible reasons:

1. If 20 minutes a reviewer also can not understand a task code, then the code itself is problematic, too complex;

2. Reviewer do not understand the business, then the developer needs to explain to reviewer, of course, do not need to explain the code can read the natural is better;

3. The task is too large and the code too much, then this task should be split and delivered in stages.

Reference resources:

Http://www.infoq.com/cn/news/2014/02/code-review-best-practice?utm_campaign=infoq_content&utm_source=infoq &utm_medium=feed&utm_term=%e7%bc%96%e7%a8%8b-news