The purpose of code review
Not to deliberately criticize a certain Coder, but to understand and learn from each other among team members, deepen members' understanding of the system, make the code of team members more robust, and discover code defects early.
So how should code review be done?
Flow Description:
1.代码送审者每次提交最好是一个完整的功能，而不是一个小功能分很多次提交。
2.代码送审时候需要填写代码说明/审核人/功能链接/bug链接
3.审查人员收到邮箱通知后，查看审查任务，进行代码评审。（需要定义一些审核规范，一些基本的规范可以通过工具在在控制，自动审核）
4.审查人员根据团队之前达成的共识（代码规范）去评审一些代码，然后给出通过或者不通过的决定
5.送审人员根据驳回的意见进行修改后，然后在次送审。
6.如果代码通过，则合并到分支库里面去。
The benefits of code reviews
Improve system maintainability
Early detection of potential defects and bugs reduces accident costs.
Promote knowledge sharing within the team and improve the overall level of the team.
The review process is also a process of thinking refactoring for reviewers, which can help more people understand the system.
Cross-reviewing code, similar to pair programming, allows each other to be familiar with each other's module business, reducing operating costs and risks due to staff turnover.
postscript:
1. It is recommended to review the code once every half month or once a month, and the review pursues quality rather than quantity. Don't overly ask programmers to do code reviews. If you force them to do an hour of code review every day, they'll quickly hate it as a boring task.
2. Code reviews are for code, not for people. Code review is learning, it's praise, it's getting feedback, and it's a very social activity. Code reviews should be fun, not boring.
Currently 100,000+ people have followed and joined us