坏味道意指代码中出现的可以被改进的地方。当你嗅到坏味道的时候，也就意味着重构的时机到了。
重构就是对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
以下是《重构》中列出的“坏味道“。
重复是代码腐朽之源。重复意味着当发生变化时，总是有很多的地方需要修改，也就是说需要对很多不同的地方负责。即使有着高级工具的辅助，对于跨函数、跨类之间的大量重复的同步修改都不会是一件轻而易举，并且能保证不会犯错的事情。
每一处重复都意味着维护时的一份责任。消除重复就可以最大化的减少职责，也降低出错的可能性。
抛开出错的可能性不谈，重复一般意味着业务逻辑的抽象还不够合理。
没有什么是增加一层“间接层”不能解决的。如果有，那就增加两层。
程序越长越难以理解。这可能与每个人大脑的结构有一定的关系，可能有些人的大脑的“栈”比较深，适应那些长函数。但对于大部分程序员、大部分人而言，太长的函数会导致“栈溢出”。
将一个长函数拆分成多个小的函数，无疑会增加更多的函数间调用。在直觉上，这样需要增加额外的开销。但是，现代OO语言几乎已经完全免除了进程内的函数调用的开销。
过大的类的一个标识就是，类中出现大量的实例变量。
不是从一个类的代码行数来判断是否类过大。而是需要从的职责来判断，如果它拥有不同的职责，那么就需要将不同的职责拆分到不同的类中。
单一职责原则。
过长的参数列表会导致难以理解，太多参数会造成前后不一致、不易使用。
传递太多的参数数据，会带来另外一个问题：很难记住参数的顺序。也就是说，不容易记住每一个参数位置传入的值分别是什么意思。如果传入的是一个对象，则可以通过对象的实例变量来取值。屏蔽了参数顺序间的问题。
但，有时候如果不希望造成“被调用对象”与“较大对象”间的某种依赖关系，这时将数据从对象中拆解出来单独作为参数也是合理的。
一个类受多种变化的影响。
针对某一外界变化的所有修改，都只应该发生在单一类中，而这个新类内的所有内容都应该反应此变化。
应该找出某特定原因而造成的所有变化，然后将它们提炼到一个类中。
一种变化引发多个类相应的修改。
也就是，逻辑概念上相近的代码被分散四处。这样导致很难寻找，也会很容易忘记某个修改。
应该把所有需要修改的代码放进同一个类中。
函数对某个类的兴趣高过对自己所处类的兴趣。这里所谓的兴趣就是指，对那个类的函数、数据的调用。
一个函数会用到几个类的功能，将它置于何处的原则：判断哪个类拥有最多被此函数使用的数据，然后就将这个函数将那些数据摆在一起。
总是捆绑出现在一起的数据应该拥有属于它们自己的对象。
不要执着于使用基本数据类型。
减少使用 switch 语句。从本质上说，它意味着重复。
可以考虑使用多态来替换它。但是对于在单一函数中出现的使用多态，有点小题大做。
当为某个类增加一个子类，必须也为另一个类相应的增加一个子类，便是出现了这个问题。
消除的策略是：让一个继承体系的实例引用另一个继承体系的实例。
对于无用的类，应该消除。这里的“无用”可能是因为重构使得它原有的工作被别的类瓜分了。
不要为了出于应对变化的目的，来将一个类打造的“过于”灵活。
变化是程序员最大的敌人。问题不在于“变化会出现”，而在于“难以预料变化出现的方式”。“变化”的粉墨登场总是会让我们措手不及。
提前就想要做好应对变化的准备，大部分时候都是挖了一条“马奇诺防线”。投入巨大，收效甚微。
我们需要让代码具有灵活性，但是过于的灵活带来的问题就是代码复杂度的增加。
对象在所有的时候被认为需要它的所有变量。对于那些仅为某种特殊情况而设置的实例变量，会使得代码难以理解。
消息链就是“开火车”，一长串的“.”会让你lost。
“不要与陌生人讲话。”
“中间人”就是把别人对它的调用“委托”给其他的对象。
对于过分亲密的类，需要移动它们的函数和实例变量来帮它们划清界限。
继承往往会造成过度亲密，因为子类对超类的了解总是超过后者的主观愿望。
两个函数做同一件事，却有不同的签名，需要根据它们的用途重新命名。
复用别人的库时，可能库不够好，而往往我们不可能修改其中的类使其完成我们希望的工作。
它们就是数据容器。不明白为什么这会被认为是一种“坏味道”。我们经常用到的"bean"。
子类应该继承超类的函数和数据。但如果不想要继承所有的数据呢？该怎么拒绝这样的“传承”。
如果需要添加注释来解释函数，或许意味着需要拆分出一些小的函数，或给函数重命名。
代码的坏味道有如厨房的油污，开始时不会觉得有多大的影响，但时间长了就会累积成“恶心”又难以“清除”的污渍。我们需要保持每天的清扫，而不是定期的“大扫除”。上面的“味道”就是一点一点的“油星”溅在“厨房”里，看到它们就顺手擦掉吧！
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 