Purpose of code review

The purpose is not to deliberately criticize a Coder, but to learn from each other among team members, deepen their understanding of the system, make the code of team members more robust, and find code defects in advance.

So how do you do code reviews?

Process description:

1. It is better for code reviewers to submit a complete feature each time, rather than a small feature multiple times. 2. Fill in code description/reviewer/function link /bug link 3 when submitting code for review. After receiving the email notification, the reviewer will view the review task and conduct code review. (Need to define some audit standards, some basic standards can be controlled by tools, automatic audit) 4. The reviewer reviews some code based on what the team previously agreed on (the code specification) and gives a pass/no-pass decision 5. Submit to the trial personnel according to the rejected opinions for revision, and then in the second trial. 6. If the code passes, it is merged into the branch library.Copy the code

Benefits of code reviews

  • Improve system maintainability

  • Early detection of potential defects and bugs, reduce the cost of accidents.

  • Promote knowledge sharing within the team to improve the overall level of the team.

  • For reviewers, the review process is also a process of thinking reconstruction, which can help more people understand the system.

  • Cross-examine code, similar to pair programming, to familiarize each other with module business and reduce operating costs and risks due to staff turnover.

Postscript:

1. Bi-monthly or monthly code reviews are recommended. Reviews are for quality rather than quantity. Don’t push programmers too hard to do code reviews. If you force them to do a code review for an hour a day, they will soon hate it as a boring task.

2. Code review is about code, not people. Code review is learning, it’s praising, it’s getting feedback, and it’s a very social activity. Code review should be fun, don’t let it get boring.