Code review during R & D

In the development process, many teams use code reviews or code Review to ensure code quality. Generally, code Review uses a collective Review.

Collective Review

Form: A team is sitting in a meeting room. One person explains his own business and code implementation, and other members of the team Review, raise questions, and discover problems and supplement deficiencies.

In this way, the following goals can be achieved:

1. Linus Law "as long as you have enough eyes, all problems will emerge ". Different people think about and understand things from different perspectives, so they discover different problems. The larger the number of people, the more comprehensive the problem is.

2. In the process of supplementing and proposing suggestions, the development standards and standards in the group can be disseminated, so that everyone can understand and unify the standards.

3. You can share your experience and knowledge when you ask questions and discover problems.

Defect: The time is too long. When the development time is short, the time pressure will be too high. Although it can reduce the cost in the later stage, for the time being, the short-term pressure.

 

Because collective Review takes a long time, it often delays everyone's time. Especially when project time is tight, the project owner may not be able to cope with the pressure, choose not to Review, or choose to Review by himself, send the question to everyone.

Owner Review

Form: the project owner performs checkout all code, Review the code one by one, and notify the relevant personnel of the detected problems by email or in person.

In this way, the following results can be achieved:

1. Avoid employee design or code problems.

2. the project owner's Development specifications and standards can be disseminated so that everyone can understand the standards.

Defects: the project owner has a high requirement and consumes too much energy to handle more key issues. At the same time, because a person reviews the problem, it is easy to omit the problem.

Later, I switched the Pair programming into the Review by referring to the idea of programming, and achieved some results.

Paired Review

Form: the project team members are paired to Review each other's code in a group. The object that rotates the Review each time.

In this form, the advantages of owner Review and collective Review are eliminated, but the two shortcomings are also eliminated, achieving a balance.

The effect is as follows:

1) When two people Review each other, they can exchange their business and experience.

2) bugs can be found in the Review process, and the narrator can also find their own bugs.

3) speeding up the Review progress. Compared with the collective Review, it can greatly improve the Review efficiency and ensure a certain effect.

4) The organizational knowledge can be fully shared, and the people in the group will view each other in pairs to fully disseminate the experience and knowledge of the members in the group.

Defect: 1) If both parties have insufficient experience, the technical exchange effect is not obvious. However, it can be supplemented by communication with another person. Therefore, it is recommended that you specify the peer Review personnel at the beginning. an experienced person should include a person with lower experience.

2) If you lack enough eyes, some bugs will be missed.

3) both parties that require Review should have a sense of responsibility. If either party is not responsible, problems may be missed.

 

The preceding three reviews have their own advantages and disadvantages. We recommend that you select or use them in Combination Based on your needs. The recommended method is 1 ~ every week ~ Two pairs of Review, each two weeks of collective Review, the R & D owner conducts spot check Review based on the situation, or strengthens the Review at the initial and later stages of the project.