1.Duplicated Code
代码重复几乎是最常见的异味了。他也是Refactoring 的主要目标之一。代码重复往
往来自于copy-and-paste 的编程风格。与他相对应OAOO 是一个好系统的重要标志
(请参见我的duplicated code 一文:http://www.erptao.org/download.php?op=viewsdownload&sid=6)。
2.Long method
它是传统结构化的“遗毒“。一个方法应当具有自我独立的意图,不要把几个意图
放在一起,我的《大类和长方法》一文中有详细描述。
3.Large Class
大类就是你把太多的责任交给了一个类。这里的规则是One Class One Responsibility。
4.Divergent Change
一个类里面的内容变化率不同。某些状态一个小时变一次,某些则几个月一年才变
一次;某些状态因为这方面的原因发生变化,而另一些则因为其他方面的原因变一次。
面向对象的抽象就是把相对不变的和相对变化相隔离。把问题变化的一方面和另一
方面相隔离。这使得这些相对不变的可以重用。问题变化的每个方面都可以单独重用。
这种相异变化的共存使得重用非常困难。
5.Shotgun Surgery
这正好和上面相反。对系统一个地方的改变涉及到其他许多地方的相关改变。这些
变化率和变化内容相似的状态和行为通常应当放在同一个类中。
6.Feature Envy
对象的目的就是封装状态以及与这些状态紧密相关的行为。如果一个类的方法频繁
用get 方法存取其他类的状态进行计算,那么你要考虑把行为移到涉及状态数目最多的
那个类。
7.Data Clumps
某些数据通常像孩子一样成群玩耍:一起出现在很多类的成员变量中,一起出现在
许多方法的参数中…..,这些数据或许应该自己独立形成对象。
8.Primitive Obsession
面向对象的新手通常习惯使用几个原始类型的数据来表示一个概念。譬如对于范围,
他们会使用两个数字。对于Money,他们会用一个浮点数来表示。因为你没有使用对象
来表达问题中存在的概念,这使得代码变的难以理解,解决问题的难度大大增加。
好的习惯是扩充语言所能提供原始类型,用小对象来表示范围、金额、转化率、邮
政编码等等。
9.Switch Statement
基于常量的开关语句是OO 的大敌,你应当把他变为子类、state 或strategy。
10. Parallel Inheritance Hierarchies
并行的继承层次是shotgun surgery 的特殊情况。因为当你改变一个层次中的某一个
类时,你必须同时改变另外一个层次的并行子类。
11. Lazy Class
一个干活不多的类。类的维护需要额外的开销,如果一个类承担了太少的责任,应
当消除它。
12. Speculative Generality
一个类实现了从未用到的功能和通用性。通常这样的类或方法唯一的用户是test
case。不要犹豫,删除它。
13. Temporary Field
一个对象的属性可能只在某些情况下才有意义。这样的代码将难以理解。专门建立
一个对象来持有这样的孤儿属性,把只和他相关的行为移到该类。最常见的是一个特定
的算法需要某些只有该算法才有用的变量。
14. Message Chain
消息链发生于当一个客户向一个对象要求另一个对象,然后客户又向这另一对象要
求另一个对象,再向这另一个对象要求另一个对象,如此如此。这时,你需要隐藏分派。
15. Middle Man
对象的基本特性之一就是封装,而你经常会通过分派去实现封装。但是这一步不能走得太远,如果你发现一个类接口的一大半方法都在做分派,你可能需要移去这个中间
人。
16. Inappropriate Intimacy
某些类相互之间太亲密,它们花费了太多的时间去砖研别人的私有部分。对人类而
言,我们也许不应该太假正经,但我们应当让自己的类严格遵守禁欲主义。
17. Alternative Classes with Different Interfaces
做相同事情的方法有不同的函数signature,一致把它们往类层次上移,直至协议一
致。
18. Incomplete Library Class
要建立一个好的类库非常困难。我们大量的程序工作都基于类库实现。然而,如此
广泛而又相异的目标对库构建者提出了苛刻的要求。库构建者也不是万能的。有时候我
们会发现库类无法实现我们需要的功能。而直接对库类的修改有非常困难。这时候就需
要用各种手段进行Refactoring。
19. Data Class
对象包括状态和行为。如果一个类只有状态没有行为,那么肯定有什么地方出问题
了。
20. Refused Bequest
超类传下来很多行为和状态,而子类只是用了其中的很小一部分。这通常意味着你
的类层次有问题。
21. Comments
经常觉得要写很多注释表示你的代码难以理解。如果这种感觉太多,表示你需要
Refactoring。
分享到:
相关推荐
"编码中的21种代码坏味道" 在设计和编码中,存在着21种代码坏味道,这些坏味道可能会给后续维护带来极大影响。如果我们能够识别和消除这些坏味道,那么我们的代码将变得更加简洁、可维护和可扩展。 Duplicated ...
标题“代码坏味道整理”指的是在编程过程中,代码可能会出现的一些不良习惯或低效的编程实践,这些被称为“代码坏味道”。这些坏味道通常会使代码难以理解、维护和扩展,降低了软件的质量。为了提高代码可读性和可...
### 《重构 改善既有代码的设计》之代码的坏味道 #### 代码的坏味道简介 重构是一种改进代码质量的重要手段,它不仅能够提升代码的可读性和可维护性,还能帮助开发者更好地理解现有系统架构。《重构 改善既有代码...
以下是一些常见的代码坏味道及其对应的重构方法: 1. **重复代码 (DRY - Don't Repeat Yourself)**:通过提炼方法、提取类等方式消除代码重复。 2. **过长方法**:可以使用提取方法来拆分长方法,提高代码可读性。...
### 代码TOP10的坏味道 #### 1. 返回值处理 在Java开发中,一个常见的问题是**返回值处理不当**。这个问题通常出现在函数调用后,如果调用方忽略了处理被调用函数的返回值,特别是当这些返回值对于后续业务逻辑有...
《重构-第3章 代码的坏味道》是软件开发领域的一本经典著作,由Martin Fowler所著。这本书深入探讨了如何识别并消除代码中的不良设计模式,以提高代码质量、可读性和可维护性。在第三章中,作者详细列举了多种"代码...
常见的代码坏味道包括: 1. **长方法**:如果一个方法执行多个职责,应考虑拆分为多个小方法,每个方法只做一件事。 2. **重复代码**:重复的代码不仅浪费存储空间,也增加了维护成本。通过创建函数或类来实现代码...
以下是我近期在代码审查中注意到的五种出现次数较多的代码坏味道,并针对每一种提供了解决建议。 1. 过大的类:遵循“单一职责原则”是编写可维护代码的关键。当一个类承担了过多的职责,变得过大时,就违反了这个...
重构-改善既有代码的设计之代码的坏味道举例说明.md
代码坏味道,也被称为“code smell”,是软件开发中用来描述代码质量低下、结构不佳或者不易理解的现象。这些坏味道可能并不直接影响程序的运行,但它们往往预示着潜在的问题,比如复杂性增加、可读性下降或维护成本...
运行效果:您的项目概览,并且可以对代码打分(百分制)根据各自的坏味道数量建立文件索引(对不同文件按照改动频率、复杂度、重复度和坏味道4个维度进行综合评定代码质量等级)坏味道检测索引可以查看具体的类文件中...
代码坏味道 什么是好代码? 什么代码复杂度? 怎么解决代码复杂性? 重要设计模式
CheckStyle 是一个静态代码分析工具,可以检测 Java 代码中的错误、坏味道和不良实践。我们可以将 CheckStyle 的 jar 文件和配置文件复制到 custom_hooks 目录下,然后在 pre-receive 钩子脚本中调用 CheckStyle ...
SonarQube 是一款强大的静态代码分析和持续代码审查平台,它能检测出代码中的潜在问题,如漏洞、坏味道(不良编程习惯)和复杂性等。SonarQube 支持多种编程语言,包括 Java、Python、C#、JavaScript 等。它提供了...
重构的实践中,识别代码中的“坏味道”至关重要。所谓“坏味道”,是指那些指向代码质量问题的不良迹象。例如,“神秘命名”、“重复代码”、“过长函数”和“发散式变化”等,这些都是代码库中经常需要关注的重构...
Fowler列举了多种常见的代码坏味道,如长方法、重复代码、开关陈述、数据泥团等,并提供了相应的检测策略。 其次,"选择合适的重构模式"是改善代码的关键。书中列举了数十种重构模式,如提取方法、提炼类、引入参数...
JavaScript代码分析技术综述对Web系统的开发和展示产生了巨大变革,但同时也带来了代码坏味道等潜在问题。 本文对1995年以来国内外会议和期刊论文进行调研,根据文献来源和主题选择了291篇高水平论文进行深入分析,...