代码的“坏味道”

如果一段代码是不稳定或有一些潜在问题的，那么代码往往包含一些明显的痕迹，就好像食物要腐败之前，经常会发出一些异味一样，这些痕迹就是代码“坏味道”。以下就是常见的代码“坏味道”。

• DuplicatedCode（重复代码）：重复是万恶之源。解决方法是将公共函数进行提取。
• LongMethod（过长函数）：过长函数会导致责任不明确、难以切割、难以理解等一系列问题。解决方法是将长函数拆分成若干函数。
• LargeClass（过长的类）：会导致责任不明确、难理解。解决方法是拆分成若干类。
• LongParameterList（过长参数列）：过长参数列其实是没有正真地遵从面向对象的编码方式，对于程序员来说也是难以理解。解决方法是将参数封装成结构或类。
• DivergentChange（发散式变化）：当对多个需求进行修改时，都会动到这种类。解决方法时对代码进行拆分，将总是一起变化的东西放在一起。
• ShotganSurgery（霰弹式修改）：其实就是再没有封装变化处改动一个需求，然后会涉及多个类被修改。解决方法是将各个修改点集中起来，抽象成一个新类。
• FeatureEnvy（依恋情结）：一个类对其他类存在过多的依赖，比如某个类使用了大量其他类的成员，这就是FeatureEnvy。解决方法是将该类并到所依赖的类里面。
• DataClumps（数据泥团）：数据泥团是常一起出现的大堆数据。如果数据是有意义的，解决方法是将结构数据转变成类。
• PrimitiveObsession（基础类型偏执）：热衷于使用int、long、String等基础类型。解决方法是将其修改成使用类的来代替。
• SwitchStatements（switch惊悚现身）：当出现switch语句判断的条件太多时，则要考虑少用switch语句，采用多态来代替。
• ParallelInheritanceHierarchies（平行继承体系）：过多平行的类，使用类继承并联起来。解决方法时将其中一个类去掉继承关系。
• LazyClass（冗赘类）：针对这个冗赘类，其解决方法是把这些不再重要的类里面的逻辑合并到相对类，并删除旧的类。
• SpeculativeGenerality（夸夸其谈未来性）：对于这些没有用处的类，直接删除即可。
• TemporaryField（令人迷惑的暂时字段）：对于这些字段，解决方法是将这些临时变量集中到一个新类中去管理。
• MessageChains（过渡耦合的消息链）：使用真正需要的函数和对象，而不要依赖宇消息链。
• MiddleMan（中间人）：存在这种过渡代理的问题，其解决方法是用继承替代委托。
• InappropriateIntimacy（狎昵关系）：两个类彼此使用对方的private值域。解决方法是划清界限拆散，或合并，或改成单项联系。
• AlternativeClasseswithDifferentInterfaces（异曲同工的类）：这些类往往是相似的类，却有不同的接口。解决方法是对这些类进行重命名、移动函数或抽象子类重复作用的类，从而合并成一个类。
• IncompleteLibraryClass（不完美的库类）：解决方法是包一层函数或包成新的类。
• DataClass（纯稚的数据类）：这些类很简单，往往仅有共有成员变量或简单的操作函数。解决方法是将相对操作封装进去，减少public成员变量。
• RefusedBequest（拒绝遗赠）：这些类的表现是父类里面方法很多，但子类只用到有限几个。解决方法是使用代理类替代继承关系。
• Comments（过多的注释）：注释多了，就说明代码不清楚了。解决方法是写注释前先重构，去掉多余的注释，“好代码会说话”。

 

出自《SpringCloud微服务架构》---柳伟卫

 

补充：

https://sourcemaking.com/refactoring/smells

https://blog.csdn.net/sulliy/article/details/6635596