How to improve team code quality--Practice of code review

Why code Review is required

Recently read some articles, found that some of the ideas of agile development more and more teams in practice, also feel that agile is no longer as early as the time so virtual, there are many tools to embody this concept emerges. Among them, "How to improve the quality of code" has been a lot of discussion, agile development also has a good variety of proposals, the most well-known, but also the most unreliable should be pairing programming, as long as the people who have not been agile brainwashed know this basic no practical operability, The idea, however, is that more than one person can supervise each other to make things better, and that is no problem at all. So there's another way to do that is code review, to change the two people at the same time to write the code at different times, one person to write, another to see. This actual development is completely achievable, just to leave the time for review.

Review the code of the team members themselves have been unconsciously doing, often go to see git log, but this way efficiency is really very low, there is no strict rules, so do more casual. happened recently to see a tone, "the more the team, the more rigorous attitude to code review", immediately aroused resonance, has long been in the heart of a way to check the code is not a feeling, but has not found the right way, and this time again Lenovo code review feel unsanitary environment, Why have you forgotten it all the time?!

If you have any questions about the benefits of code review, please read this article on the Phabricator website carefully.

How code is reviewed

There are two main ways of code review:

1. Pre-push: Before submitting the merge code, review, pass and be merged. This is a very rigorous review that ensures that each published code is reviewed. This is ideal for open source projects maintained on GitHub, where the owner of the code can ensure that the code is within its control.

2. Post-push: After the code is submitted, review the previous code. This is a very lenient examination, and the effect of the review is certainly discounted, but the advantage is that it can be overlooked by some unnecessary scrutiny to save time. In fact, this is not a lot of engineer culture in the country, this way is relatively good early implementation.

Tools for code Review

This thing in the team, it is necessary to have a tool, the relevant tools are many, the review method is also biased. Here are some of the main tools to solve these problems:

1 A more intuitive interface to see diff.

2. Simple tagging and notification can be done based on tools, and writing tags directly into the code is more conducive to communication.

3. It is possible to know which submissions have been reviewed by WHO, facilitating the review of collaboration.

Before in SF wrote a question and answer can be consulted. Here are some examples, for reference to choose.

1. Gerrit:google products, fame is very big, but this thing design concept is relatively old, it is said that there is no maintenance, not recommended.

2. GitHub Pull Request: This of course is very good, the typical Pre-push way, but the personal use also does not have much to cooperate the thing, the team use and feel expensive. Actually feel with BitBucket will be economical and practical.

3. Phabricator:facebook internal use and open source tools, features super powerful, but the relative is very complex, the interface design is very European and American style, running speed is a bit slow. Things are still very good, see if you like it.

4. Gitlab: If you build your own git server, this is a good choice, equivalent to get a GitHub, that is, the configuration of the environment will be more workload.

5. Upsource:jetbrains products, only post-push way, but from the installation, interface, to use are very good, the only problem is 10 people above the charge, but also very expensive.

We benefit from it.

Choose Which way, I think because of team culture, project background, effect is expected, we finally selected is Upsource, the goal is to first in the Team code review execution.

At present, the effect is also possible. With the tools to do each other code review is also more convenient, psychological resistance is not so strong. In fact, as long as the progress is not so urge, developers are more willing to do this kind of thing. The review process has found some code problems, but there are not many, I think as long as the problem can be solved before the bug, there is a lot of value.

How to improve team code quality--Practice of code review