background

I initiated the code review of the team at first, but the effect was not very good after two or three times. Therefore, I re-read some opinions on code review on the Internet and sorted them out. Meanwhile, I continued to make best practices in subsequent teams
At present, the team mainly relies on Alibaba’s protocol scanning tool and SonarQube plug-in

Common controversy

Why do code reviews when there’s no time to do a project
- In our team, it’s usually once a month, and the team members take turns doing it
- The loss and cost of not reviewing and not testing is greater
It takes too much time and is usually a matter of changing formatting, comments, naming and so on
- Both technology and business are indispensable, and neither can be examined better without either. Business and technology can be reviewed separately as appropriate, and those unfamiliar with the business can be eaten together with the code and design documents
The team has a habit of not doing code reviews
- Try to talk to the leader or project manager about the benefits
Bad for team building because of arguments in code review due to different views
- It is not necessarily a bad thing to control a certain intensity of argument. In the process of argument, comprehensive abilities such as analysis, thinking, weighing, induction and expression can be exercised

One of the best ways to improve yourself and your team
Effective way to build team relationship and expand the influence of both sides
- Praise what is well done
Identify design flaws and find safety, performance, dependencies, compatibility issues that are not easily detected by testing
Set the team quality benchmark

The amount of code per change should be small
Great people play a role in the team
The quality of the changes is greater than the current code base average
- Constructive and secondary suggestions
New employee code, skeleton code review needs to be more stringent
Express affirmation in time and express opinions tactfully
- The code, not the person
- If I persist, I won’t convince you
- Soften your point of view with uncertain words like maybe, maybe, etc
- Indirect negation, use questions. Why do they make such a good match
- Put chestnuts on and discuss links to support your own views
- Yes, then no, but then it turns around
In the examination, we should focus on the main problems first and look at the secondary problems second time
- Start by figuring out the mechanics of the code, and ask big, constructive questions
- There are levels of priority for solving big problems

Code quality check SonarQube
- Sonarlint plugin for IDEA
- www.cnblogs.com/throwable/p…
- Local tried to download a run up, the feeling is more convenient
GitLab CI/CD