1. The right thing is wrong to the person. Everyone is a colleague, and it is important to work in a team. Don't say "what kind of garbage you wrote" in Code Review, you can say "this variable name is not easy to understand, is it better for us to change to Barabara".
2. Give at least one positive review for each Review. The original intention of Code Review is to improve code quality and enhance communication between team members. However, as soon as I submit the code, some people say that I wrote rubbish. This is a blow to self-confidence, and it is not conducive to peace with team members. There is a problem with the code. It is necessary to point out the problem and seek truth from facts, but sometimes it is necessary to encourage teammates.
3. Ensure the readability of the published code and review comments. Everyone is a programmer. When you submit the code, you should not only conform to the team's style, but also make the code more attractive. If you know where your code is insufficient, Highlight will come out for your comments. If you are here to review the code, make your comments clear and structured. To `embed code with backquotes ( ) or ```write code blocks with three backquotes ( ), it is much more comfortable and efficient
4. Use tools to automate the inspection of basic issues. Use Tab or space, use two spaces or four spaces, how to wrap after the function and other basic problems, you can use similar tools such as eslint and Rubocop . Team members should focus more on code specification, code performance optimization, etc. local.
5. All members participate in Code Review and set the person in charge of each part. Enlarge the participation of Code Review. Participation does not mean that we must review other people's code. It can be the code being reviewed or the review opinions of others. This is a learning process. And each part sets the person in charge who is responsible for the quality of this part of the code, and the person in charge needs to be a senior engineer. Full participation in Code Review can make team members grow faster, and newcomers can learn a lot by watching the code review of the boss.
6. The content of each code PR must be small. The effect and quality of Code Review is inversely proportional to the amount of PR code. If you submit so much code at once, am I still off work today? Will you help me with my girlfriend? The amount of PR code is small each time, it seems to be fast, and it does not lose patience, so as to achieve the effect of Code Review, so Code Review must be performed frequently, but the amount of each PR code is small. I recommend less than 300 lines/PR.
7. Before writing new code, review the code that needs to be reviewed. You asked me to review the code a week ago? I have to switch my thinking and project schedule to a week ago? Everyone is definitely not willing, so it is necessary to form a rule to discard the old review before writing the new code, and ensure that the amount of code is small when submitting the PR, so that the review does not require a lot of time and the change is quick. You can't greatly delay the progress of the project because of Code Review. The progress is a matter of the whole team, not a person.
8. If you have a better plan, just suggest it. In Code Review, you will often find bad writing. If you have a better method, please suggest it! First of all, to improve the code of this PR, and secondly to reflect your ability, the team should regularly reward such colleagues who propose good solutions.
9. Don't discuss requirements in review, review is review. Don't do anything else in Code Review. If necessary, arrange another time for it. Make it clear that Code Review is to improve the code, not to discuss requirements and functions. Always focus on code quality.