怎么做code review

我们现在的code review的方式是在提测前甚至在提测后，开始review，这样有几个弊端：

1. 一次性进行很大批量的code review，是review不出来什么东西的，只能看看最表面
2. 在提测之前或者提测之后进行code review，如果是比较大的问题，或者review出来的问题比较多，相关开发修改的时间是有限的
   因此，更加推荐使用pr（mr）级别的code review。
   先介绍一下code review的好处
   团队知识共享：
3. 通过代码审查，高手可以直接指出新手代码中的问题，新手可以马上从高手的反馈中学习到好的实践，得到更快的成长
4. 新人成长了，可以帮老人多分担一些任务
5. 代码审查中花了时间，就可以减少后续一些帮新人做的业务擦屁股的时间
6. 良好的沟通、发现问题的能力、帮助其他人成长都是技术上更上一层楼必不可少的能力，通过代码审查可以有效提升这些能力
   提升代码质量
7. 提升代码的可读性、可维护性
8. 一些特定条件下的隐患或者安全漏洞，可能测试都无法测试出来，代码审查却可以发现
9. 高手也需要代码被审查：（1）别人通过阅读高手的代码，可以学习到很多好的编码实践（2）高手的代码肯定也有一些问题的，就像考试中，学习好的学生也要在写完试卷后，自己检查一遍
   编码规范
10. 我发现很多人有时候，明知写的代码不符合编码规范，但是因为没有人审查他们的代码，写代码是“明知故犯”（写一段行数很长的方法、故意用变量而不用常量）
11. 有了代码审查机制，写代码的人就会心里有杆秤，会尽量把代码写规范，因为知道有人要review自己的代码
    降低维护成本
    我们开发的代码，如果写的不好，开发用了2天，可能在后续的迭代和查找线上问题的时候，要多花5天去维护
    现在都有什么code review的方式？
    现在code review的方式有哪几种：
    • 面对面：reviewer和author一起面对面查看代码，代码有问题，reviewer直接指出，author后面修改，这种方式要两个人一起review，消耗掉了所有reviewer和author的时间，优点是面对面沟通更直接
    • 设置栅栏：就是author在自己的开发分支开发，在合并到测试分支的时候在gitlab提交一个mr请求，code reviewer进行code review，如果有问题提出来问题，问题修改掉后再合并到测试分支，设置栅栏有一个优点是，让提交代码者心里有了敬畏，知道代码是要被review的，并且要review通过才能合并到测试分支的，让review者平时写代码的时候不敢再轻易写出烂代码。
    • 不设栅栏：author先提交代码到测试分支，在后续reviewer再进行code review，这个方案的缺点是：开发者可以随意往测试分支提交代码，code reviewer后续找时间review，这种方式可能导致提交到测试分支的代码是有问题的，后续提出了代码问题，author修不修改都看author自己。
    怎么样做code review?
    总和比较后，我比较倾向于使用“开发阶段设栅栏，提测后不设栅栏”的方式进行code review
12. 每个人都有自己的开发分支，设置测试分支的push权限
13. 在gitlab上，可以设置指定的分支只有master等级的开发者才能推送到指定分支
14. merge request并选定提交人
15. 代码审核人发表代码审查的意见，全部修改后，将问题置为resolved，当所有问题都被解决后，审核人点击merge按钮即可
16. 所有人在gitlab上把代码merge request到测试分支，1-2天一次，在pull request后相关人员code review代码，如果code review通过则merge到测试分支，如果review不通过，则在gitlab上面标记出来问题，问题分为两个等级：error：必须要修改的，warn：建议修改的，
17. code review是互相学习进步的方式，不要带有贬低损的词汇口吻
18. 开发在排期的时候就要把相关code review的人员想好，并在排期的时候将code review的时间排进去，以每两天一次code review，一次1小时为标准
19. 以上流程在开发过程中是没有问题的，如果在提测后，还要code review后才能merge到测试分支，反应就有些慢了，会影响测试的进度了，此时可以，在测试环境修改测试分支的权限，devloper可以提交推送到测试分支，还是2天code review一次，但是先测试环境发布，后code review。
20. 根据个人习惯，还可以通过idea插件安装代码审查gitlab代码审查的功能我们现在的code review的方式是在提测前甚至在提测后，开始review，这样有几个弊端：
21. 一次性进行很大批量的code review，是review不出来什么东西的，只能看看最表面
22. 在提测之前或者提测之后进行code review，如果是比较大的问题，或者review出来的问题比较多，相关开发修改的时间是有限的
    因此，更加推荐使用pr（mr）级别的code review。
    先介绍一下code review的好处
    团队知识共享：
23. 通过代码审查，高手可以直接指出新手代码中的问题，新手可以马上从高手的反馈中学习到好的实践，得到更快的成长
24. 新人成长了，可以帮老人多分担一些任务
25. 代码审查中花了时间，就可以减少后续一些帮新人做的业务擦屁股的时间
26. 良好的沟通、发现问题的能力、帮助其他人成长都是技术上更上一层楼必不可少的能力，通过代码审查可以有效提升这些能力
    提升代码质量
27. 提升代码的可读性、可维护性
28. 一些特定条件下的隐患或者安全漏洞，可能测试都无法测试出来，代码审查却可以发现
29. 高手也需要代码被审查：（1）别人通过阅读高手的代码，可以学习到很多好的编码实践（2）高手的代码肯定也有一些问题的，就像考试中，学习好的学生也要在写完试卷后，自己检查一遍
    编码规范
30. 我发现很多人有时候，明知写的代码不符合编码规范，但是因为没有人审查他们的代码，写代码是“明知故犯”（写一段行数很长的方法、故意用变量而不用常量）
31. 有了代码审查机制，写代码的人就会心里有杆秤，会尽量把代码写规范，因为知道有人要review自己的代码
    降低维护成本
    我们开发的代码，如果写的不好，开发用了2天，可能在后续的迭代和查找线上问题的时候，要多花5天去维护
    现在都有什么code review的方式？
    现在code review的方式有哪几种：
    • 面对面：reviewer和author一起面对面查看代码，代码有问题，reviewer直接指出，author后面修改，这种方式要两个人一起review，消耗掉了所有reviewer和author的时间，优点是面对面沟通更直接
    • 设置栅栏：就是author在自己的开发分支开发，在合并到测试分支的时候在gitlab提交一个mr请求，code reviewer进行code review，如果有问题提出来问题，问题修改掉后再合并到测试分支，设置栅栏有一个优点是，让提交代码者心里有了敬畏，知道代码是要被review的，并且要review通过才能合并到测试分支的，让review者平时写代码的时候不敢再轻易写出烂代码。
    • 不设栅栏：author先提交代码到测试分支，在后续reviewer再进行code review，这个方案的缺点是：开发者可以随意往测试分支提交代码，code reviewer后续找时间review，这种方式可能导致提交到测试分支的代码是有问题的，后续提出了代码问题，author修不修改都看author自己。
    怎么样做code review?
    总和比较后，我比较倾向于使用“开发阶段设栅栏，提测后不设栅栏”的方式进行code review
32. 每个人都有自己的开发分支，设置测试分支的push权限
33. 在gitlab上，可以设置指定的分支只有master等级的开发者才能推送到指定分支
34. merge request并选定提交人
35. 代码审核人发表代码审查的意见，全部修改后，将问题置为resolved，当所有问题都被解决后，审核人点击merge按钮即可
36. 所有人在gitlab上把代码merge request到测试分支，1-2天一次，在pull request后相关人员code review代码，如果code review通过则merge到测试分支，如果review不通过，则在gitlab上面标记出来问题，问题分为两个等级：error：必须要修改的，warn：建议修改的，
37. code review是互相学习进步的方式，不要带有贬低损的词汇口吻
38. 开发在排期的时候就要把相关code review的人员想好，并在排期的时候将code review的时间排进去，以每两天一次code review，一次1小时为标准
39. 以上流程在开发过程中是没有问题的，如果在提测后，还要code review后才能merge到测试分支，反应就有些慢了，会影响测试的进度了，此时可以，在测试环境修改测试分支的权限，devloper可以提交推送到测试分支，还是2天code review一次，但是先测试环境发布，后code review。
40. 根据个人习惯，还可以通过idea插件安装代码审查gitlab代码审查的功能