代码味道识别工具 (Code Smell Detection Tools, CSDT)
既可以应用于软件开发阶段,也可以应用于软件维护阶段。目前大部分IDE都集成了自动或者半自动重构工具,但是
根据国外研究人员的调查发现,真正在软件开发和维护中使用重构工具的人并不多,其中有一个很重要的原因是不知道何时该重构,也就是说找不准重构时机
,因此重构时机的自动识别具有很大的实用价值。很多代码味道本身就是重构时机的指示器,如果能够自动发现这些代码味道,就说明代码中存在一些不恰当的设计方案或者程序代码,在此时再实施重构将有利于提高代码质量。
当前大部分CSDT在发现代码味道之后并不能实施自动重构(在接下来要介绍的七款工具中,只有JDeodorant提供了重构功能),还好现代IDE都自带了重构功能,尽管很多重构还是需要用户参与,只是半自动重构,但是这已经比人工重构好很多了。人工重构主要存在两个问题:
(1) 重构效率低 。特别是对于一些较为复杂的重构,如果全部按照Martin Fowler书中的示例一步步操作,效率很低,使得重构这一非创造性工作耗费大量的时间和精力,划不来,不可取。
(2) 人工重构容易犯错 。只要程序本身正确,并能够通过严格的正确性和可靠性测试,自动重构的结果往往比人工重构的结果很准确,而人工重构的质量需要取决于重构人员本身的经验,一不小心就会存在一些错误的重构或者重构不完整。
本文将对七款CSDT进行简要的介绍(如果有时间的话在后续博客中再对这些工具分别进行详细的说明),并提供了下载链接,没有用过的童鞋可以试着用用,使用过的童鞋也欢迎与Sunny交流使用心得,特别是对这些工具有什么意见和建议,这对Sunny当前的研究工作很有帮助,
。
【注:如果不明白这些代码味道的具体含义,请参阅: 22种代码味道(Martin Fowler与Kent Beck) ,URL: /content/749422.html 。】
(1) Checkstyle
URL: http://checkstyle.sourceforge.net/
Checkstyle是一款知名度很高的静态代码分析工具,用于帮助程序员按照一些代码标准来编写Java代码,它内置了许多规则,可以验证Java代码是否符合这些预定义的规则。Checkstyle可以检测Large Class,Long Method,Long Parameter List和Duplicated Code四种代码味道。
(2) DECOR
URL: http://www.ptidej.net/research/designsmells/
DECOR由Moha等人设计和开发,它定义了一组方法用于自动检测设计和代码味道(又称为反模式Anti-Pattern)。他们使用定制的语言描述了八种代码味道(分别是Data Class,Large Class,Long Method,Long Parameter List,Message Chains,Refused Bequest,Speculative Generality,Tradition Breaker),并使用模板自动生成它们的探测算法,最后依据精确率(Precision)和召回率(Recall)来验证这些算法,在DECOR中实现了这些用于软件分析的算法。DECOR既是Moha等提出的方法的名字,也是他们所开发的代码味道检测工具的名字。
【注:获取DECOR的安装程序需要向作者(PtidejTeam)发电子邮件,邮箱地址:decor@ptidej.net】
(3) iPlasma
URL: http://loose.upt.ro/iplasma/
iPlasma是一个用于评估面向对象系统质量的集成平台,它涉及模型提取、高层度量分析等多个方面。iPlasma用于检测一些作者预先定义的代码问题,这些问题主要分为三类:身份问题(Identity Disharmonies)、协作问题 (Collaboration Disharmonies)和分类问题(Classification Disharmonies),关于这些问题的详细介绍可以参考 Object-Oriented Metrics in Practice: Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented Systems 一书,这些问题中包括不少代码味道,例如Duplicated Code(在iPlasma中叫做Significant Duplication),God Class,Feature Envy和Refused Bequest等。当然,iPlasma并没有实现Object-Oriented Metrics in Practice中所有问题的探测,在Object-Oriented Metrics in Practice一书中,身份问题(Identity Disharmonies)包括God Class,Feature Envy,Data Class,Brain Method,Brain Class和Significant Duplication,协作问题 (Collaboration Disharmonies)包括Intensive Coupling,Dispersed Coupling和Shotgun Surgery,分类问题(Classification Disharmonies)包括Refused Parent Bequest和Tradition Breaker。对这些味道及其详细说明感兴趣的童鞋可以看看 Refactoring: Improving the Design of Existing Code 和 Object-Oriented Metrics in Practice: Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented Systems 这两本书。
(4) inFusion
URL: http://www.intooitus.com/inFusion.html
inFusion是iPlasma的商业版本,因此inFusion的功能比iPlasma更加强大,不过因为它是一款商业软件,所以很多功能需要购买正式版才能使用,而且价格还不便宜,下图是最新的价格表,价格单位是欧元哦,欧元!
inFusion能够探测超过20中代码味道和代码缺陷,在本文所介绍的七种工具中是最多的,不过也就它要钱,它能够探测到的代码味道包括重复代码,破坏封装的类(如数据类或者万能类),高耦合的方法和类,以及一些设计不合理的类继承结构。
(5) JDeodorant
URL: http://www.jdeodorant.com/
从学术的角度来说,JDeodorant是一款很强大的工具,催生了多篇高水平研究论文的诞生。它是一个Eclipse插件,可以用于自动识别Java程序中存在的Feature Envy,God Class,Long Method和Switch Statement(在JDeodorant中称为Type Checking)等代码味道。针对识别到的代码问题,JDeodorant将向用户提供多种合适的重构方案,并按照它们对设计的影响进行排序,然后将排序结果呈现给开发人员以供开发人员选择,最后还能够自动实施所选择的重构手段。
(6) PMD
URL: http://pmd.sourceforge.net/ 和 https://github.com/pmd
PMD在代码静态分析领域知名度非常高,它可以扫描Java源代码并寻找代码中潜在的问题或者可能存在的bug,例如dead code(死代码),empty try/catch/finally/switch statement(空的语句块),unusedlocal variables or parameters(没有使用的局部变量或参数)和duplicated code(重复代码)等。PMD也可以探测一些代码味道,例如Large Class,Long Method,Long Parameter List和Duplicated Code等,它允许用户在探测这些代码味道时设置一些探测度量因子的阈值,例如Large Class和Long Method的代码行数,Long Parameter List的方法参数个数,Duplicated Code中重复代码的数量等,这些都可以由用户自己来设定。
(7) Stench Blossom
URL: http://people.engr.ncsu.edu/ermurph3/tools.html
Stench Blossom是一个提供了交互式可视化环境的味道识别工具,它可以向程序员快速提供一个代码味道的高层视图以及味道的来源。Stench Blossom也是一个Eclipse插件,它向程序员提供了三个不同的视图,通过这三个视图逐步以可视化方式提供更多关于这些代码味道的信息。它最终以可视化方式返回一个综合的反馈结果,在IDE中以花瓣图的方式来表示代码单元,花瓣的大小与某一代码单元中存在的味道“强度”成正比,也就是说存在的代码味道越多,对应的花瓣越大。寻找这些代码味道的唯一可能方法就是人工审查源代码,主要是分析那些存在代码味道的大花瓣。Stench Blossom可以探测到8种代码味道,分别是Data Clumps,Feature Envy,Instanceof,Large Class,Long Method,Message Chains,Switch Statement和Typecast。这些味道有些并不属于Martin Flower所定义的22种经典代码味道。
表1对这七个工具的一些基本特征进行了总结,不难看出:所有的工具都可以对Java代码进行味道识别,部分工具可以识别C/C++中的代码味道;有一些工具作为单机版(Standalone)发布,也有一些工具作为Eclipse插件(Plugin)发布;只有JDeodorant提供了自动重构(Refactoring)功能;部分工具只能检测到代码中存在的味道,但是没有对所识别到的味道进行定位。具体情况如表1所示:
表2对这七个工具所能够探测到的代码味道进行了统计,作为商业工具的inFusion所能够识别到的代码味道最多(12种),其次是iPlasma(11种)。
表2中一共包括21种代码味道,但并非所有味道都是Martin Fowler在《重构》一书中定义的那22种代码味道。本文所介绍的七种工具最多也就能够识别一半味道多一点,不知道新版本是否可以识别更多的味道。如果能够识别到更多的味道(除了这21种外,还有一些其他的代码味道),而且识别速度还过得去,我想应该可以开发出更强大的代码味道识别工具,
。
由于不同的代码味道识别工具的实现原理不同,因此,对于同一种代码味道,不同的工具的识别结果并不一定相同,有国外学者对这些工具的准确率进行了比较,不同的工具对于某种(些)味道可能具有一些优势,但对于其他味道可能效果并不是最好。缺乏统一的标准和规范,这也是当前代码味道识别所面临的一个问题,国内从事相关研究和工具开发的人较少,很多企业对于代码质量的重视程度不够,导致代码味道识别工具的推广和使用并不太给力,希望在将来会有所好转。
除上述七款工具之外,还有一些用于探测代码味道的工具和方法。例如CodeVizard (基于Object-Oriented Metrics in Practice一书所定义的探测规则),inCode(基于inFusion的Eclipse插件),ExCop (for .NET),Analyst (for Java,商业软件),JCosmo (for Linux),CloneDigger和ConQat(用于克隆检测),其中,克隆检测工具应该是最多的,Sunny计划整理一篇专门的博文来介绍常用的克隆检测工具。
本文中所介绍的这些工具大家都可以试着用用,结合Eclipse中的Refactoring菜单一起使用应该有利于提高代码质量。如有代码味道识别和重构方面的问题,欢迎与Sunny交流讨论!
当前大部分CSDT在发现代码味道之后并不能实施自动重构(在接下来要介绍的七款工具中,只有JDeodorant提供了重构功能),还好现代IDE都自带了重构功能,尽管很多重构还是需要用户参与,只是半自动重构,但是这已经比人工重构好很多了。人工重构主要存在两个问题:
(1) 重构效率低 。特别是对于一些较为复杂的重构,如果全部按照Martin Fowler书中的示例一步步操作,效率很低,使得重构这一非创造性工作耗费大量的时间和精力,划不来,不可取。
(2) 人工重构容易犯错 。只要程序本身正确,并能够通过严格的正确性和可靠性测试,自动重构的结果往往比人工重构的结果很准确,而人工重构的质量需要取决于重构人员本身的经验,一不小心就会存在一些错误的重构或者重构不完整。
本文将对七款CSDT进行简要的介绍(如果有时间的话在后续博客中再对这些工具分别进行详细的说明),并提供了下载链接,没有用过的童鞋可以试着用用,使用过的童鞋也欢迎与Sunny交流使用心得,特别是对这些工具有什么意见和建议,这对Sunny当前的研究工作很有帮助,
![](http://static.blog.csdn.net/xheditor/xheditor_emot/default/smile.gif)
。
【注:如果不明白这些代码味道的具体含义,请参阅: 22种代码味道(Martin Fowler与Kent Beck) ,URL: /content/749422.html 。】
(1) Checkstyle
URL: http://checkstyle.sourceforge.net/
Checkstyle是一款知名度很高的静态代码分析工具,用于帮助程序员按照一些代码标准来编写Java代码,它内置了许多规则,可以验证Java代码是否符合这些预定义的规则。Checkstyle可以检测Large Class,Long Method,Long Parameter List和Duplicated Code四种代码味道。
(2) DECOR
URL: http://www.ptidej.net/research/designsmells/
DECOR由Moha等人设计和开发,它定义了一组方法用于自动检测设计和代码味道(又称为反模式Anti-Pattern)。他们使用定制的语言描述了八种代码味道(分别是Data Class,Large Class,Long Method,Long Parameter List,Message Chains,Refused Bequest,Speculative Generality,Tradition Breaker),并使用模板自动生成它们的探测算法,最后依据精确率(Precision)和召回率(Recall)来验证这些算法,在DECOR中实现了这些用于软件分析的算法。DECOR既是Moha等提出的方法的名字,也是他们所开发的代码味道检测工具的名字。
【注:获取DECOR的安装程序需要向作者(PtidejTeam)发电子邮件,邮箱地址:decor@ptidej.net】
(3) iPlasma
URL: http://loose.upt.ro/iplasma/
iPlasma是一个用于评估面向对象系统质量的集成平台,它涉及模型提取、高层度量分析等多个方面。iPlasma用于检测一些作者预先定义的代码问题,这些问题主要分为三类:身份问题(Identity Disharmonies)、协作问题 (Collaboration Disharmonies)和分类问题(Classification Disharmonies),关于这些问题的详细介绍可以参考 Object-Oriented Metrics in Practice: Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented Systems 一书,这些问题中包括不少代码味道,例如Duplicated Code(在iPlasma中叫做Significant Duplication),God Class,Feature Envy和Refused Bequest等。当然,iPlasma并没有实现Object-Oriented Metrics in Practice中所有问题的探测,在Object-Oriented Metrics in Practice一书中,身份问题(Identity Disharmonies)包括God Class,Feature Envy,Data Class,Brain Method,Brain Class和Significant Duplication,协作问题 (Collaboration Disharmonies)包括Intensive Coupling,Dispersed Coupling和Shotgun Surgery,分类问题(Classification Disharmonies)包括Refused Parent Bequest和Tradition Breaker。对这些味道及其详细说明感兴趣的童鞋可以看看 Refactoring: Improving the Design of Existing Code 和 Object-Oriented Metrics in Practice: Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented Systems 这两本书。
(4) inFusion
URL: http://www.intooitus.com/inFusion.html
inFusion是iPlasma的商业版本,因此inFusion的功能比iPlasma更加强大,不过因为它是一款商业软件,所以很多功能需要购买正式版才能使用,而且价格还不便宜,下图是最新的价格表,价格单位是欧元哦,欧元!
![](http://static.blog.csdn.net/xheditor/xheditor_emot/default/laugh.gif)
inFusion能够探测超过20中代码味道和代码缺陷,在本文所介绍的七种工具中是最多的,不过也就它要钱,它能够探测到的代码味道包括重复代码,破坏封装的类(如数据类或者万能类),高耦合的方法和类,以及一些设计不合理的类继承结构。
(5) JDeodorant
URL: http://www.jdeodorant.com/
从学术的角度来说,JDeodorant是一款很强大的工具,催生了多篇高水平研究论文的诞生。它是一个Eclipse插件,可以用于自动识别Java程序中存在的Feature Envy,God Class,Long Method和Switch Statement(在JDeodorant中称为Type Checking)等代码味道。针对识别到的代码问题,JDeodorant将向用户提供多种合适的重构方案,并按照它们对设计的影响进行排序,然后将排序结果呈现给开发人员以供开发人员选择,最后还能够自动实施所选择的重构手段。
(6) PMD
URL: http://pmd.sourceforge.net/ 和 https://github.com/pmd
PMD在代码静态分析领域知名度非常高,它可以扫描Java源代码并寻找代码中潜在的问题或者可能存在的bug,例如dead code(死代码),empty try/catch/finally/switch statement(空的语句块),unusedlocal variables or parameters(没有使用的局部变量或参数)和duplicated code(重复代码)等。PMD也可以探测一些代码味道,例如Large Class,Long Method,Long Parameter List和Duplicated Code等,它允许用户在探测这些代码味道时设置一些探测度量因子的阈值,例如Large Class和Long Method的代码行数,Long Parameter List的方法参数个数,Duplicated Code中重复代码的数量等,这些都可以由用户自己来设定。
(7) Stench Blossom
URL: http://people.engr.ncsu.edu/ermurph3/tools.html
Stench Blossom是一个提供了交互式可视化环境的味道识别工具,它可以向程序员快速提供一个代码味道的高层视图以及味道的来源。Stench Blossom也是一个Eclipse插件,它向程序员提供了三个不同的视图,通过这三个视图逐步以可视化方式提供更多关于这些代码味道的信息。它最终以可视化方式返回一个综合的反馈结果,在IDE中以花瓣图的方式来表示代码单元,花瓣的大小与某一代码单元中存在的味道“强度”成正比,也就是说存在的代码味道越多,对应的花瓣越大。寻找这些代码味道的唯一可能方法就是人工审查源代码,主要是分析那些存在代码味道的大花瓣。Stench Blossom可以探测到8种代码味道,分别是Data Clumps,Feature Envy,Instanceof,Large Class,Long Method,Message Chains,Switch Statement和Typecast。这些味道有些并不属于Martin Flower所定义的22种经典代码味道。
表1对这七个工具的一些基本特征进行了总结,不难看出:所有的工具都可以对Java代码进行味道识别,部分工具可以识别C/C++中的代码味道;有一些工具作为单机版(Standalone)发布,也有一些工具作为Eclipse插件(Plugin)发布;只有JDeodorant提供了自动重构(Refactoring)功能;部分工具只能检测到代码中存在的味道,但是没有对所识别到的味道进行定位。具体情况如表1所示:
表2对这七个工具所能够探测到的代码味道进行了统计,作为商业工具的inFusion所能够识别到的代码味道最多(12种),其次是iPlasma(11种)。
表2中一共包括21种代码味道,但并非所有味道都是Martin Fowler在《重构》一书中定义的那22种代码味道。本文所介绍的七种工具最多也就能够识别一半味道多一点,不知道新版本是否可以识别更多的味道。如果能够识别到更多的味道(除了这21种外,还有一些其他的代码味道),而且识别速度还过得去,我想应该可以开发出更强大的代码味道识别工具,
![](http://static.blog.csdn.net/xheditor/xheditor_emot/default/struggle.gif)
。
由于不同的代码味道识别工具的实现原理不同,因此,对于同一种代码味道,不同的工具的识别结果并不一定相同,有国外学者对这些工具的准确率进行了比较,不同的工具对于某种(些)味道可能具有一些优势,但对于其他味道可能效果并不是最好。缺乏统一的标准和规范,这也是当前代码味道识别所面临的一个问题,国内从事相关研究和工具开发的人较少,很多企业对于代码质量的重视程度不够,导致代码味道识别工具的推广和使用并不太给力,希望在将来会有所好转。
![](http://static.blog.csdn.net/xheditor/xheditor_emot/default/laugh.gif)
除上述七款工具之外,还有一些用于探测代码味道的工具和方法。例如CodeVizard (基于Object-Oriented Metrics in Practice一书所定义的探测规则),inCode(基于inFusion的Eclipse插件),ExCop (for .NET),Analyst (for Java,商业软件),JCosmo (for Linux),CloneDigger和ConQat(用于克隆检测),其中,克隆检测工具应该是最多的,Sunny计划整理一篇专门的博文来介绍常用的克隆检测工具。
本文中所介绍的这些工具大家都可以试着用用,结合Eclipse中的Refactoring菜单一起使用应该有利于提高代码质量。如有代码味道识别和重构方面的问题,欢迎与Sunny交流讨论!