怎么做code review
2024-05-10 22:07:51
我们现在的code review的方式是在提测前甚至在提测后，开始review，这样有几个弊端：
- 一次性进行很大批量的code review，是review不出来什么东西的，只能看看最表面
- 在提测之前或者提测之后进行code review，如果是比较大的问题，或者review出来的问题比较多，相关开发修改的时间是有限的
因此，更加推荐使用pr（mr）级别的code review。
先介绍一下code review的好处
团队知识共享： - 通过代码审查，高手可以直接指出新手代码中的问题，新手可以马上从高手的反馈中学习到好的实践，得到更快的成长
- 新人成长了，可以帮老人多分担一些任务
- 代码审查中花了时间，就可以减少后续一些帮新人做的业务擦屁股的时间
- 良好的沟通、发现问题的能力、帮助其他人成长都是技术上更上一层楼必不可少的能力，通过代码审查可以有效提升这些能力
提升代码质量 - 提升代码的可读性、可维护性
- 一些特定条件下的隐患或者安全漏洞，可能测试都无法测试出来，代码审查却可以发现
- 高手也需要代码被审查：（1）别人通过阅读高手的代码，可以学习到很多好的编码实践（2）高手的代码肯定也有一些问题的，就像考试中，学习好的学生也要在写完试卷后，自己检查一遍
编码规范 - 我发现很多人有时候，明知写的代码不符合编码规范，但是因为没有人审查他们的代码，写代码是“明知故犯”（写一段行数很长的方法、故意用变量而不用常量）
- 有了代码审查机制，写代码的人就会心里有杆秤，会尽量把代码写规范，因为知道有人要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 - 每个人都有自己的开发分支，设置测试分支的push权限
- 在gitlab上，可以设置指定的分支只有master等级的开发者才能推送到指定分支
- merge request并选定提交人
- 代码审核人发表代码审查的意见，全部修改后，将问题置为resolved，当所有问题都被解决后，审核人点击merge按钮即可
- 所有人在gitlab上把代码merge request到测试分支，1-2天一次，在pull request后相关人员code review代码，如果code review通过则merge到测试分支，如果review不通过，则在gitlab上面标记出来问题，问题分为两个等级：error：必须要修改的，warn：建议修改的，
- code review是互相学习进步的方式，不要带有贬低损的词汇口吻
- 开发在排期的时候就要把相关code review的人员想好，并在排期的时候将code review的时间排进去，以每两天一次code review，一次1小时为标准
- 以上流程在开发过程中是没有问题的，如果在提测后，还要code review后才能merge到测试分支，反应就有些慢了，会影响测试的进度了，此时可以，在测试环境修改测试分支的权限，devloper可以提交推送到测试分支，还是2天code review一次，但是先测试环境发布，后code review。
- 根据个人习惯，还可以通过idea插件安装代码审查gitlab代码审查的功能我们现在的code review的方式是在提测前甚至在提测后，开始review，这样有几个弊端：
- 一次性进行很大批量的code review，是review不出来什么东西的，只能看看最表面
- 在提测之前或者提测之后进行code review，如果是比较大的问题，或者review出来的问题比较多，相关开发修改的时间是有限的
因此，更加推荐使用pr（mr）级别的code review。
先介绍一下code review的好处
团队知识共享： - 通过代码审查，高手可以直接指出新手代码中的问题，新手可以马上从高手的反馈中学习到好的实践，得到更快的成长
- 新人成长了，可以帮老人多分担一些任务
- 代码审查中花了时间，就可以减少后续一些帮新人做的业务擦屁股的时间
- 良好的沟通、发现问题的能力、帮助其他人成长都是技术上更上一层楼必不可少的能力，通过代码审查可以有效提升这些能力
提升代码质量 - 提升代码的可读性、可维护性
- 一些特定条件下的隐患或者安全漏洞，可能测试都无法测试出来，代码审查却可以发现
- 高手也需要代码被审查：（1）别人通过阅读高手的代码，可以学习到很多好的编码实践（2）高手的代码肯定也有一些问题的，就像考试中，学习好的学生也要在写完试卷后，自己检查一遍
编码规范 - 我发现很多人有时候，明知写的代码不符合编码规范，但是因为没有人审查他们的代码，写代码是“明知故犯”（写一段行数很长的方法、故意用变量而不用常量）
- 有了代码审查机制，写代码的人就会心里有杆秤，会尽量把代码写规范，因为知道有人要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 - 每个人都有自己的开发分支，设置测试分支的push权限
- 在gitlab上，可以设置指定的分支只有master等级的开发者才能推送到指定分支
- merge request并选定提交人
- 代码审核人发表代码审查的意见，全部修改后，将问题置为resolved，当所有问题都被解决后，审核人点击merge按钮即可
- 所有人在gitlab上把代码merge request到测试分支，1-2天一次，在pull request后相关人员code review代码，如果code review通过则merge到测试分支，如果review不通过，则在gitlab上面标记出来问题，问题分为两个等级：error：必须要修改的，warn：建议修改的，
- code review是互相学习进步的方式，不要带有贬低损的词汇口吻
- 开发在排期的时候就要把相关code review的人员想好，并在排期的时候将code review的时间排进去，以每两天一次code review，一次1小时为标准
- 以上流程在开发过程中是没有问题的，如果在提测后，还要code review后才能merge到测试分支，反应就有些慢了，会影响测试的进度了，此时可以，在测试环境修改测试分支的权限，devloper可以提交推送到测试分支，还是2天code review一次，但是先测试环境发布，后code review。
- 根据个人习惯，还可以通过idea插件安装代码审查gitlab代码审查的功能
怎么做code review相关推荐
- Google是如何做Code Review的？| CSDN原力计划
作者 | 帅昕 xindoo 编辑 | 屠敏 出品 | CSDN 博客 我和几个小伙伴一起翻译了Google前一段时间放出来的Google's Engineering Practices docume ...
- 万字详文告诉你如何做 Code Review
点击上方"小白学视觉",选择加"星标"或"置顶" 重磅干货,第一时间送达本文转自|机器学习实验室 前言 作为公司代码委员会 golang 分 ...
- 在腾讯，如何做 Code Review？
作者:cheaterlin,腾讯 PCG 后台开发工程师 前言 作为公司代码委员会 golang 分会的理事,我 review 了很多代码,看了很多别人的 review 评论.发现不少同学 code ...
- 你有做 Code Review 吗？
在代码的编写中有一个很重要的环节,经常会被忽视,那就是 Code Review ,据说在 Facebook.Google 这种互联网大公司,要求每一个提交都必须通过审查,对于每个工程师来说 Code ...
- 在腾讯，如何做 Code Review
作为公司代码委员会 golang 分会的理事,我 review 了很多代码,看了很多别人的 review 评论.发现不少同学 code review 与写出好代码的水平有待提高.在这里,想分享一下我的 ...
- Google 是如何做 Code Review 的？| 原力计划
作者 | 帅昕 xindoo 责编 | 屠敏 出品 | CSDN 博客 我和几个小伙伴一起翻译了Google前一段时间放出来的Google's Engineering Practices docume ...
- Google是如何做Code Review的
我和几个小伙伴一起翻译了Google前一段时间放出来的Google's Engineering Practices documentation,翻译后的github仓库https://github.c ...
- 万字详文告诉你如何做 Code Review！
作者:cheaterlin,腾讯PCG后台开发工程师 来源:腾讯技术工程 前言 作为公司代码委员会 golang 分会的理事,我 review 了很多代码,看了很多别人的 review 评论.发现不少 ...
- 在腾讯，我们如何做 Code Review
推荐关注 扫码关注"中生代技术",选择"星标"公众号 重磅干货,第一时间送达!责编:架构君 | 作者:cheaterlin,腾讯 PCG 后台开发工程师 | ...
- 如何做Code Review——读后感
文章链接:万字详文告诉你如何做 Code Review! 最近阅读到这篇文章,觉得不错,就仔细阅读理解并做了笔记 为什么要做Code Review! riview过程中做到落地沟通,在实际问题中产生思 ...
最新文章
- 【指标统计】标记存量遥控（成功/失败）遥信（正确/错误）
- 学习shell脚本之乘法口诀
- springboot(七)：springboot+mybatis多数据源最简解决方案
- C语言文件操作（四）将txt格式汉字转化为txt格式16进制编码
- 在东岸听刘元演奏萨克斯
- oracle日志存放默认位置,oracle——数据库日志存放位置
- liunx 下mysql 的安装（转载）
- Quartz配置文件
- 卡巴斯基正式版 送一年
- 帆软客户画像分析与客户价值模型
- pytorch求STFT
- 有关密钥的最全总结都在这了
- unsw计算机专业排名,2019上海软科世界一流学科排名计算机科学与工程专业排名新南威尔士大学排名第76-100...
- JQuery动态生成Table表格
- 求和计算机教案,面试真题gt;小学信息技术《自动求和》教学设计
- Appium的常用定位方法
- c语言程序设计循环结构实验报告,C语言程序设计实验报告选择与循环结构程序设计.doc...
- php怎么登录后显示用户名和密码错误,首页登录后怎么在首页显示用户名以及隐藏登录框？...
- python使用turtle绘制奥运五环
- 涿州蓝天计算机学校,涿州职教中心计算机专业高考班人才培养方案.doc