干掉你代码中的坏味道

  1. 云栖社区>
  2. 博客>
  3. 正文

干掉你代码中的坏味道

听云 2016-09-14 11:27:20 浏览1139
展开阅读全文

原文出自【听云技术博客】:http://blog.tingyun.com/web/article/detail/1094

最近团队开始抓代码质量了,总结一下自己的经验,先看看坏代码有哪些特点:

1.png

“都一样,不幸的家庭却各有不同”,这句话放到代码里也同样适用。接下来,我们聊一聊如何解决坏代码问题。 


如果我问你,“你们是如何保证团队代码质量的”,你的回答可能是:“我们每次写完代码,都会花一些时间review一下。” 


恩,做的确实不错,但是,做的还不够,除非你是门门考试都100的学霸,否则,借助一些工具还是比较稳妥的办法。 


在这里简单介绍一个代码分析工具RubyCritic,这是一个专门针对Ruby的一个静态代码分析工具。其它语言的,也有相似功能的工具链,我就不做介绍了。 


这是一个命令行工具,第一步就是添加到你的gem库中,当然,还可以使用guard自动化分析。(Ruby的世界,你懂得~) 第二step,在console运行【RubyCritic】命令,就像这样:  

2.png

在命令的最后,会生成一个静态页面。长这个样子:  

3.png

x轴代表改动频率,Y轴代表代码复杂程度 


这是分析结果的overview,超过200的复杂度的,基本都是坏代码。 


再看看code里的内容: 

4.png

对不同文件按照改动频率、复杂度、重复度和坏味道4个维度进行综合评定代码质量等级(和美国考试的成绩打分规则一样)。  


再看看Smell里的内容 : 

5.png

6.png

7.png

8.png

RubyCritic对代码分析的原理,其实就是分析一些,被它认为是坏代码的点。注意,我这里使用的措辞是“被它认为,所以,有时候,它不是绝对的正确。” 还可以查看具体的类文件中的代码质量问题。

9.png

更多的介绍,详见 https://github.com/whitesmith/rubycritic  


下面,我们针对RubyCritic给我们的一些坏代码的点,有针对性的做些代码调整。

10.png

 


这里使用git diff 比较新旧版本的差异。operator原来是实例方法,代码行7,并且里面还有一个if结构体。started_time_and_node 原来是实例方法,代码行4,并且里面还不止一个if结构体。 


笔者review的方式:


1.实例方法修改为类方法(减少混入方法,解耦合,减低负责度)


2.多使用Ruby原生链式操作(减少中间变量,更少的代码,对于脚本语言,就是更快的执行效率,而且很多原生方法是C语言实现。)


3.去掉结构体 (现代编程语言的结构体,让代码具有丰富的逻辑性和可读性,但是缺点就是cpu的额外开销。)  


以上部分,属于语法层面的奇技淫巧。      


第二部分,我们从设计角度分析一下。

11.png

它的代码行只有141行,方法也只有7个。但是评级却是C。再看看代码分析细节,这里就展现一小部分,简直就是惨不忍睹,不好意思全展现给大家看了。        

12.png

13.png

14.png

没有人会一开始就这样写代码,这种坏代码,永远都是渐渐变馊的。不过笔记仔细想来,当年遇到过比着还馊1000倍的代码(1000倍都不算过分)。            


这是笔者做的第一版重构结果。


这里使用了策略模式。Stats_hash不再是充当一个集合的作用,现在变成了一个环境类,将原来依赖if结构数据分装到不同的行为类中。 

15.png

第二版的改动计划是,引入work-job的模式,并发执行4个job。


第三版改动计划就是利用回调方式,去掉与该类不相干的代码,将逻辑分装到行为类里。    


好了,写到这里,基本的代码层面的优化思路就这些了,其它就是开支散叶的过程,这里就不冗余了。下一节,咱俩聊一聊性能优化的一些思路。

网友评论

登录后评论
0/500
评论
听云
+ 关注