【有奖调查】代码审查时你都会关注哪些方面的问题?

红薯
 红薯
发布于 2018年09月04日
收藏 7

代码审查有奖调查:请在评论中回答如下两个问题:

问题1

如果从 0 ~ 10 表示代码审查的重要性,那么你认为代码审查重要性得分是多少呢?

问题2

如果做代码审查时,你一般会关注哪些方面的问题?

参与方法

请直接在评论中提交你的答案,答案格式如下:

问题1: x
问题2: 1. xxxxxx, 2. xxxxxx, 3. xxxxxx

评选规则

评论内容与本主题相匹配,符合以上参与方法中的内容格式。

有奖调查时间:9月4日 ~ 9月7日

我们将从参与调查的答案中选择 3 个点赞数量最多的评论+随机抽取两个评论(共5人)赠予码云宇宙最大耍酷无敌桌布大鼠标垫一张(不包含鼠标垫上的笔记本电脑、马克杯以及红薯绿植)。

------- 广告分割线 --------

团队协作开发中,无规矩不成方圆。代码审查是你避免被猪队友坑死的最有效方法。可是代码审查怎么做,审查些什么方面的内容,这是决定代码审查工作是否成功最重要的因素。

在功能和业务方面我们帮不了你什么,但是码云企业版刚刚推出了 Pull Requests 的自动质量检查,开发人员提交了代码合并后,系统将自动分析出代码中存在的各种类型问题:包括代码规范、严重的 Bug 等等。

下图展示了某个项目提交完在合并之前的一个审查界面:

在这个 login.js 中共发现了 16 个不同的问题,这些问题给代码合并审查人员提供了非常有效直观的数据,来决定是否进行代码的合并操作。大大的节省了繁重的代码审查工作。

目前该服务只提供给码云企业版的客户使用。

欢迎体验码云企业版 https://gitee.com/enterprises

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:【有奖调查】代码审查时你都会关注哪些方面的问题?
加载中

精彩评论

宇润
宇润
问题1: 10

不过对于大部分野鸡公司来讲,代码审查不存在的,快速完成任务上线完事。反正也是快速交付给客户,要么就是做出来没访问量……

问题2:

1. 代码格式是否规范(这个要看公司是否有相关规定咯,能统一尽量统一要求)

2. 是否重复开发了已有的公共方法,为了后期方便维护,我会统一封装一些方法和组件

3. 可读性,尽量少用奇淫技巧,那些看着酷实际难以阅读的不能写

4. 注释,类、方法、关键地方是否有注释说明,注释不要求多,但要简洁明了

5. 业务逻辑,和预想的逻辑是否一致,大部分野鸡公司没有测试岗位,在运行前只能靠人眼来看。

6. 性能,如果有特别严重影响性能的写法用法,应该改正

7. 是否定义了常量,比如:不要用1、2、3来表示状态,而是应该有对应的常量,可读性强

8. 调试代码是否去除了

暂时能想到的就这么多了……
LeoXu
LeoXu
问题1: 10
问题2: 1. 通过谈话了解审查对象的工作经验,性格等, 2.业务逻辑, 3. 代码的排版是否美观, 3. 注释, 4.高级语法的运用
不应有的淡定
不应有的淡定
1.逻辑是否清晰,是否存在冗余代码
2.代码是否简洁,少些if else嵌套,按照功能细分
3.是否存在明显的多余判断,或者存在没有处理异常的情况
4.是否可复用,能否提到公用组件
5.可读性是否高,是否存在必要注释
笑傲软件园
笑傲软件园
我的话一般会关注这些:
1.编码是否工整,规范(空格,换行,命名,注释等)
2.if else 等可读性问题,while(true){} 死循环问题(合理性),线程sleep 问题(合理性)等
3.代码结构化问题(复用,扩展等)
4.ide 软件的报警提醒等
我一直很淡定
我一直很淡定
1.10
2.1.符合公司规范 2.代码逻辑要清晰,业务逻辑先忽略(后面交给测试)

最新评论(53

KillBiYuan
KillBiYuan
问题1: 8
问题2:
1. 主要是杜绝死循环,用jstack检查Java线程,杜绝死循环,避免CPU和内存高占用;
2. 注释和代码可读性;
3. 其他我觉得没什么要求,可能是我境界还不够,基层码农一个:sweat_smile:!
DragoonKiller
DragoonKiller
问题1: 8分
问题2:
1. 代码格式规范.
2. 代码效力. 检查是否真正实现了功能, 是否达到了预期的目标.
3. 结构设计. 检查代码是否有越俎代庖的行为, 是否有无效的关联/依赖, 是否做出了过分的抽象或提前优化, 对通用组件做出的修改是否向前向后兼容, 对于大型commit还要检查其内部各个类,函数,变量等的对外兼容性和从外部进行侵入式修改/读取的难易程度.
4. 代码可读性.
5. 对于用于性能优化的commit, 还要重点评估需求变更时的灵活程度.
克虏伯
克虏伯
问题1: 看公司,如果是小公司,初创期,代码审查2分。如果是大点的公司,那么,代码审查7分,因为中、大公司要制度完备、认真执行,所以只有代码审查占较大比重,才能让代码质量保持在一定的水平,这样即使人员流动,也不至于项目垮了。小公司,开始期,目的是保持快速开发、生存;中大公司,已经有了一定的市场,一定的资金,所以更致力于平衡、平稳发展。
lijuec
lijuec

引用来自“宇润”的评论

问题1: 10

不过对于大部分野鸡公司来讲,代码审查不存在的,快速完成任务上线完事。反正也是快速交付给客户,要么就是做出来没访问量……

问题2:

1. 代码格式是否规范(这个要看公司是否有相关规定咯,能统一尽量统一要求)

2. 是否重复开发了已有的公共方法,为了后期方便维护,我会统一封装一些方法和组件

3. 可读性,尽量少用奇淫技巧,那些看着酷实际难以阅读的不能写

4. 注释,类、方法、关键地方是否有注释说明,注释不要求多,但要简洁明了

5. 业务逻辑,和预想的逻辑是否一致,大部分野鸡公司没有测试岗位,在运行前只能靠人眼来看。

6. 性能,如果有特别严重影响性能的写法用法,应该改正

7. 是否定义了常量,比如:不要用1、2、3来表示状态,而是应该有对应的常量,可读性强

8. 调试代码是否去除了

暂时能想到的就这么多了……
什么叫做野鸡公司?
lijuec
lijuec
问题1:7 考虑时间成本和项目的实际开发情况 但是项目必须过规定的checkstyle(后台和前台)
问题2:
1.不检查业务的正确与否
2.检查变量和函数的命名是否清晰,清晰程度一定程度上是否体现了业务的熟悉程度
2.检查接口定义,是否存在不安全的隐患
3.复杂业务查看具体的逻辑流程,避免无用的,多余的操作
4.前端检查函数,查看是否有内存泄漏的可能和对象重复生成的操作
5.后端从返回数据追溯到接口,查看是否存在不安全的操作 如可能的异常未做捕获或连接未释放等
6.强制检查所有的递归
7.略微查看一下sql的写法是否有优化的地方
LeoXu
LeoXu
问题1: 10
问题2: 1. 通过谈话了解审查对象的工作经验,性格等, 2.业务逻辑, 3. 代码的排版是否美观, 3. 注释, 4.高级语法的运用
Kervon
Kervon
问题1: 10
问题2: 1. 可读性注释是否齐全, 2. 检查逻辑漏洞, 3. 是否健壮性
lanrain
lanrain
问题1: 8分,如果时间宽裕,审查确实很重要
问题2:
1. 代码风格,良好统一的代码风格可增加代码审查的速度
2. 命名规范,不得不说命名是写程序的一大难题
3. 明显的业务逻辑错误及代码错误
4. 统一的公共处理
5. 代码优化
葉者
葉者
1.编码是否工整,规范(空格,换行,命名,注释等)
2.代码是否简洁,少些if else嵌套,按照功能细分,是否导入不需要的类包
3.是否高可读性,是否存在必要注释
4.逻辑清晰程度,是否存在冗余代码
5.是否存在没有处理异常的情况
6.是否可复用,能否提到公用组件
有志向的小羊
有志向的小羊
问题1:10
做银行项目时代码审查非常严格,日志、金额部分、循环、SQL都要经过严格的审查;离开帝都后回到小城市,代码审查不严了,eclipse使用checkstyle过一下没大问题,然后再看下复杂业务部分,金额支付部分就OK了。

问题2:
1、项目结构:要按模块规划好项目结构,做到不乱写;
2、复用程度:能复用的部分就提取出来;
3、命名规范:根据功能做好命名,看其名知其意思;
4、代码注释:代码注释做好模板,统一导入,要求每个类、方法都要做注释;
5、复杂业务逻辑:逻辑复杂部分重点看下,没问题就行;
6、订单支付金额:由于做金融行业久了,这块特别重视,设计支付、转账的一定要反复审查;
7、SQL审查:此部分大致看下,没有无用关联,功能实现即可;
返回顶部
顶部