最近团队开始抓代码质量了，总结一下自己的经验，先看看坏代码有哪些特点：
“都一样,不幸的家庭却各有不同”，这句话放到代码里也同样适用。接下来，我们聊一聊如何解决坏代码问题。
如果我问你，“你们是如何保证团队代码质量的”，你的回答可能是：“我们每次写完代码，都会花一些时间review一下。”
恩，做的确实不错，但是，做的还不够，除非你是门门考试都100的学霸，否则，借助一些工具还是比较稳妥的办法。
在这里简单介绍一个代码分析工具RubyCritic，这是一个专门针对Ruby的一个静态代码分析工具。其它语言的，也有相似功能的工具链，我就不做介绍了。
这是一个命令行工具,第一步就是添加到你的gem库中，当然，还可以使用guard自动化分析。（Ruby的世界，你懂得~） 第二step，在console运行【RubyCritic】命令，就像这样：
在命令的最后，会生成一个静态页面。长这个样子：
x轴代表改动频率，Y轴代表代码复杂程度
这是分析结果的overview，超过200的复杂度的，基本都是坏代码。
再看看code里的内容：
对不同文件按照改动频率、复杂度、重复度和坏味道4个维度进行综合评定代码质量等级（和美国考试的成绩打分规则一样）。
再看看Smell里的内容 ：
RubyCritic对代码分析的原理，其实就是分析一些，被它认为是坏代码的点。注意，我这里使用的措辞是“被它认为，所以，有时候，它不是绝对的正确。” 还可以查看具体的类文件中的代码质量问题。
更多的介绍，详见 https://github.com/whitesmith/rubycritic
下面，我们针对RubyCritic给我们的一些坏代码的点，有针对性的做些代码调整。
这里使用git diff 比较新旧版本的差异。operator原来是实例方法，代码行7，并且里面还有一个if结构体。started_time_and_node 原来是实例方法，代码行4，并且里面还不止一个if结构体。
笔者review的方式：
1.实例方法修改为类方法（减少混入方法，解耦合，减低负责度）
2.多使用Ruby原生链式操作（减少中间变量，更少的代码，对于脚本语言，就是更快的执行效率，而且很多原生方法是C语言实现。）
3.去掉结构体 （现代编程语言的结构体，让代码具有丰富的逻辑性和可读性，但是缺点就是cpu的额外开销。）
以上部分，属于语法层面的奇技淫巧。
第二部分，我们从设计角度分析一下。
它的代码行只有141行，方法也只有7个。但是评级却是C。再看看代码分析细节，这里就展现一小部分，简直就是惨不忍睹，不好意思全展现给大家看了。
没有人会一开始就这样写代码，这种坏代码，永远都是渐渐变馊的。不过笔记仔细想来，当年遇到过比着还馊1000倍的代码（1000倍都不算过分）。
这是笔者做的第一版重构结果。
这里使用了策略模式。Stats_hash不再是充当一个集合的作用，现在变成了一个环境类，将原来依赖if结构数据分装到不同的行为类中。
第二版的改动计划是，引入work-job的模式，并发执行4个job。
第三版改动计划就是利用回调方式，去掉与该类不相干的代码，将逻辑分装到行为类里。
好了，写到这里，基本的代码层面的优化思路就这些了，其它就是开支散叶的过程，这里就不冗余了。下一节，咱俩聊一聊性能优化的一些思路。