如果一个人没有听说过《重构》这本书，那么他一定不敢说自己是程序员；如果一个人没有阅读过《重构》这本书，那么很难想象他会是一名优秀的程序员。这本书是很多公司要求Java程序员必读的三本书之一（另外两本书是《Java编程思想》和《Effective Java》），其实无关编程语言，是程序员就能够从这本书中受益。 何谓重构？重构是对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低修改成本。重构是用微小的步伐修改程序，在这个过程中也能够很容易的发现程序中的错误。重构的时机可以是添加功能时，也可以是修补错误时，还可以是复审代码时。重构的目标是让代码容易阅读、所有逻辑都在唯一地点指定、新的改动不会危及现有行为、尽可能简单的表达逻辑。 这本书我个人最喜欢的第三章 – “代码的坏味道”，因为我喜欢在写完代码后去思考我的代码中有没有这些坏味道，然后再去想一想应该如何重构代码。这本书的作者是世界级的软件开发大师Martin Fowler，他也被誉为软件开发“教父”，同时他还是敏捷开发的创始人之一。Martin Fowler编写了很多极好的书籍，包括《企业应用架构模式》、《领域特定语言》、《NoSQL精粹》、《分析模式：可重用对象模型》等。Martin Fowler给出的代码的坏味道包括： – Duplicated Code（重复代码）：“代码有很多中坏味道，重复是最坏的一种”，这句话我经常讲给自己的学生听，但是他们真正领悟并践行这句话的人却不多。一个类中的两个方法有重复代码，那么一定可以通过抽取方法的方式将重复代码放到另一个方法中以供调用；两个互为兄弟的子类中如果有重复代码可以将其重复代码抽取到父类中；两个没有关系的类中如果有重复代码，那么可以重新抽取一个类将重复代码放到这个第三方类中。 – Long Method（长的方法）：程序越长理解起来就越困难，这已经是常识了，使用短小的方法首先符合高内聚的要求，同时也可以给通过给方法起一个好的名字来帮助理解方法的作用。如果感觉到方法的某个地方需要注释来说明什么，那么可以把这些东西放入一个独立的方法中，并以用途（注意不是实现手法）来命名方法。 – Large Class（巨大的类）：如果希望写一个类来做很多的事情，那么最终势必导致重复和混乱的代码。类的设计应当遵循单一职责原则（SRP）。重构一个巨大的类可以使用抽取接口的方式来搞清楚这个类应该如何分解。 – Long Parameter List（长参数列表）：这个对于做过Windows编程或者用过MFC（Microsoft Foundation Class）的程序员来说再熟悉不过了，Windows函数和MFC中的方法那些长得变态的参数列表对程序员来说都是恶梦。重构的方式很多，比较常见的是将相关的参数组织成一个对象来替换掉这些参数。 – Divergent Change（分散的可变性）和Shotgun Surgery（散弹式手术）：这两种坏味道前者讲的是新功能难以加入，，后者说的是某种变化会引发多个细节的修改。简单的说如果程序中的可变因素散落在代码的各个角落中，那么代码的维护将是一场恶梦。重构的方法是找到特定原因造成的所有变化，然后将它们抽取到另一个类中。设计模式中的桥梁模式就是为了解决这一问题而提供的解决方案。 – Feature Envy：这个真没想到如何翻译会比较容易理解，简单的说就是一个方法从另一个类的对象那里获取许多的值，重构的方案是将该方法移到另一个类中。听起来很简单，但是在实践的时候却经常会忘了这么做。 – Data Clumps（数据群集）：状况类似于长参数列表。 – Primitive Obsession（基本类型偏执）。一个类中如果有很多基本类型的成员，通常可以考虑将不同的基本类型分散组装成对象，就像Hibernate中的组合映射那样，将一个类的对象嵌入到另一个类中作为其成员而不是只写一个类，里面有很多基本数据类型的成员。 – Switch Statements（重复的switch语句）：面向对象程序的一个明显特征就是用多态替换掉switch结构，因为这种switch结构会在多个地方重复。 – Parallel Inheritance Hierarchies（平行继承结构）：情况跟Shortgun Surgery差不多，可以使用桥梁模式进行重构。 – Lazy Class（冗余类）：如果一个类不值得存在，那么它就应该消失。 – Speculative Generality（投机通用性）：如果你的抽象类、委托、方法的参数没有实际的作用，那么就应当被移除掉。 – Temporary Field（临时字段）：类中某个字段只为某些特殊情况而设置。 – Message Chains（消息链）：我个人并没有感觉到这个有多么坏。 – Middle Man（中间人）：如果一个类的很多功能都通过委托给其他类来完成，那么就不如去掉这些中间人直接和真正负责的对象打交道。 – Inappropriate Intimacy（过于亲密）：使用继承复用代码会经常性的引发这种问题，因为子类对父类的了解总是超过后者的主观愿望，如果你觉得这个孩子可以独立生活了，就应该让它离开继承体系，这一点跟面向对象设计原则中的合成聚合复用原则不谋而合。 – Alternative Classes with Different Interfaces（异曲同工）：两个方法做同一件事情却有着不同的签名。 – Incomplete Library Class（不完整类库）。 – Data Class（数据类）：类的退化结构。我们在分层开发中经常使用的失血模型（事务脚本模式）中的业务实体不就是数据类吗，这明显与面向对象的思想是背道而驰的。 – Refused Bequest（拒绝遗产）：如果子类复用了父类的行为，又不愿意支持父类的接口，可以考虑用合成关系聚合关系取代继承关系来消除这种坏味道。 – Comments（注释劣质代码）：注释不是用来补救劣质代码的，事实上如果我们去除了代码中的所有坏味道，当劣质代码都被移除的时候，注释已经变得多余，因为代码已经讲清楚了一切。
彻底根除代码中这些坏味道的方法在《重构》一书的第六章到第十二章，提供了约70条重构建议，其中一部分常用的重构建议在IDE的重构菜单中也能找到。Eclipse和IntelliJ的重构菜单分别如下面两张图所示。 Eclipse的重构菜单：
IntelliJ的重构菜单：
偶尔，我一个人站在黄昏的荒野，
