代码异味

(重定向自代码坏味道

程序开发领域,代码中的任何可能导致深层次问题的症状都可以叫做代码异味(Code smell)。

通常,在对代码做简短的反馈迭代时,代码异味会暴露出一些深层次的问题,这里的反馈迭代,是指以一种小范围的、可控的方式重构代码。基于这些暴露的问题,人们会进一步的检查设计和代码中是否还存在别的代码异味,然后再做进一步的重构。从负责重构的开发者的角度来看,代码异味可以启发何时重构,如何重构。因此,可以说代码异味推动着重构的进行。

该术语似乎由肯特·贝克于90年代后期,在WardsWiki上首次使用。且自从在Refactoring. Improving the Design of Existing Code.[1]被提到过,使用率就大大的提高。代码异味同时也是敏捷开发者常用的术语。

什么是,或者不是代码异味,是一个主观的判断,通常因语言、开发者、开发方法的不同而不同。对于Java开发语言,有些工具,比如CheckstylePMDFindBugs可以自动检测一些代码异味。

常见的代码异味

编辑
  • 代码重复: 相同或者相似的代码存在于一个以上的地方。
  • 长方法: 一个非常长的方法、函数或者过程。
  • 巨类: 一个非常庞大的类。
  • 太多的参数: 函数或者过程的冗长的参数列表使得代码可读性和质量非常差。
  • 特性依恋: 一个类过度的使用另一个类的方法。
  • 亲密关系: 一个类依赖另一个类的实现细节。
  • 拒绝继承: 子类以一种‘拒绝’的态度,覆盖基类中的方法,换句话说,子类不想继承父类中的方法,参考里氏替换原则
  • 冗余类 / 寄生虫: 一个功能太少的类。
  • 人为的复杂: 在简单设计已经满足需求的时候,强迫使用极度复杂的设计模式。
  • 超长标识符: 尤其,在软件工程中,应该毫无保留的使用命名规则来消除歧义。
  • 超短标识符: 除非很明显,一个变量名应该反映它的功用。
  • 过度使用字面值: 为提高可读性和避免编码错误,应该使用命名常量。此外,字面值可以且应该在可能的情况下,独立存放于资源文件或者脚本中,在软件部署到不同区域时,可以很方便地本地化。

参见

编辑

引用

编辑

外部链接

编辑