一、 目的
改善和保证代码质量，预防BUG，此外还有益于代码规范，形成技术氛围，加深团队沟通，一起成长。
二、 具体事项
1、对人不对事：每个人对代码的理解与实现方式都不一样，不应该对同事的代码加以批判，可以提出建议。
2、每一次Review至少给出一次正面的评价：在严格要求与实事求是的前提下，不要只说一些打击同事信心的话，应该给予一些适当的鼓励，还能让团队更加融洽，氛围更好。
3、保证发布代码的可读性：大家都是程序员，提交代码的时候，在符合团队风格的同时，尽量把代码弄得简洁，精炼。对于一些自己把握不足的点，可以标记起来，供同事一起讨论；如果是你是Review代码的，那么就把建议表述通畅。看的更舒服，效率更高。
4、每次PR的内容要少：Code Review 效果和质量与 PR 代码量成反比，内容过多，会让Review的人对代码失去耐心，代码量适中可以提高效率，建议少于300/PR。
5、在写新代码之前，先Review掉需要评审的代码：如果评审的代码不断堆积，那么一段时间后，对代码的印象会下降，代码量会提升。还得把对项目的认识退到那个时间点。对团队的项目进度有很大的影响。
6、如果在Review的过程中，你有更好的方案，那么请你提出来，方便自己，造福他人。
7、在Review的过程中，只讨论完善代码与性能，不应该讨论需求与功能，以代码质量为中心。
8、全员参加Code Review：参与不是说一定要去审核别人的代码，也可以是代码被审核。对于代码的审查，所有的开发人员都应该是能看到，无论是源代码，审查的建议，替代的方案。这对于我们来说也是一次学习的机会，加快成长。每个成员对应自己独立的分支，在自己的分支上开发代码，每个成员负责另外一个成员的代码审查，形成一个有效循环，给出意见或者更好的实现方案，经过互相沟通，确定代码方案，更行最新的代码，审查通过组长便将个人独立分支代码合并到开发分支。
9、用工具进行辅助：对于使用idea工具，推荐一款插件SonarLint，他可以对代码进行分析审查并且可出替换方案，一些不合适的书写方式，潜在的BUG等。
三、 基于GitLab的code review
1、在服务器搭建GitLab环境，配置用户相关信息，在本地idea上配置好git环境。
2、新建项目流程操作如下：
3、对项目分支进行配置，不同分支的push/merge操作权限配置：
4、创建对应分支流程：
5、加入用户到这这个项目，给予权限：
6、通过git clone -b dev将项目克隆到本地，对应修改，push到dev，在gitlab项目的页面发起merge请求。以及对应修改描述信息等：
下图是对提交的代码的细节进行描述，以及合并到那个分支等信息：
7、对应审查角色在页面可以看到其他开发人员发起的请求，通过查看相关代码的，给予建议或者新的解决方案：
8、以上是给予GitLab实现code review的大致过程，仅供参考，如有更好的解决方案请提出。
四、 对于本项目的review的简单配置方案
1、分支构成：
1、master：线上版本，不能在此做任何操作，除合并分支外。
2、dev：开发分支，所有用户可进行push、merge操作。
3、test：测试分支，用于review，当用户从dev merge test时，会将此请求发送到对应项目管理权限的用户，进行审查操作。
4、为了更好维护项目版本代码，可以使用每个开发人员单独分支进行独立开发。
2、项目权限配置
1、master：不可push，管理员权限可merge。
2、dev：可push，可merge。
3、test：不可push，管理员权限可merge。
3、合并请求方案
1、项目包含的所有用户对于发起的请求都是可见的，包括代码修改以及建议。
2、只有管理员权限可以对请求进行审核，并判断是否能通过。