基本信息
- 原书名：Refactoring: Improving the Design of Existing Code
- 原出版社： Addison-Wesley Professional
- 作者： (美)Martin Fowler
- 丛书名： 图灵程序设计丛书.程序员修练系列
- 出版社：人民邮电出版社
- ISBN：9787115168047
- 上架时间：2013-5-9
- 出版日期：2008 年2月
- 开本：16开
- 页码：471
- 版次：1-1
- 所属分类：计算机 > 软件工程及软件方法学 > 设计模式
编辑推荐
软件开发的不朽经典
生动阐述重构原理和具体做法
新添大量重构方法，使你与时俱进
丰富的词汇和背景注释，助你轻松读经典
内容简介
作译者
Martin Fowler世界软件开发大师，在面向对象分析设计、UML、模式、XP和重构等领域都有卓越贡献，现为著名软件开发咨询公司ThoughtWorks的首席科学家。他的多部著作《分析模式》、《UML精粹》和《企业应用架构模式》等都已经成为脍灸人口的经典。
目录
Chapter 1：Refactoring，a First Example 重构，第一个例子
The Starting Point 起点
The First Step in Refactoring 重构第一步
Decomposing and Redistributing the Statement Method 分解并重组slalemenl方法
Replacing the Conditional Logic on Price Code with Polymorphism 用多态代替价格条件逻辑代码
Final Thoughts 结语
Chapter 2：Principles in Refactoring 重构原则
Defining Refactoring 何谓重构
Why Should You Refactor? 为何重构
When Should You Refactor? 何时重构
What Do I Tell My Manager? 怎样说服经理
Problems with Refactoring 重构的问题
Refactoring and Design 重构与设计
Refactoring and Performance 重构与性能
Where Did Refactoring Come From? 重构的起源
Chapter 3：Bad Smells in Code(by Kent Beck and Martin Fowler) 代码坏昧
Duplicated Code 重复代码
Long Method 过长方法
Large Class 过长类
Long Parameter List 过长参数列表
The Starting Point 起点
The First Step in Refactoring 重构第一步
Decomposing and Redistributing the Statement Method 分解并重组slalemenl方法
Replacing the Conditional Logic on Price Code with Polymorphism 用多态代替价格条件逻辑代码
Final Thoughts 结语
Chapter 2：Principles in Refactoring 重构原则
Defining Refactoring 何谓重构
Why Should You Refactor? 为何重构
When Should You Refactor? 何时重构
What Do I Tell My Manager? 怎样说服经理
Problems with Refactoring 重构的问题
Refactoring and Design 重构与设计
Refactoring and Performance 重构与性能
Where Did Refactoring Come From? 重构的起源
Chapter 3：Bad Smells in Code(by Kent Beck and Martin Fowler) 代码坏昧
Duplicated Code 重复代码
Long Method 过长方法
Large Class 过长类
Long Parameter List 过长参数列表
前言
从前，有一位顾问受邀为一个软件开发项目做咨询。这个顾问看了看开发人员已编写的一些代码，他发现系统的中心是一个类层次结构。浏览这个结构时，他发现它非常凌乱，上层类对类的工作方式做了一些假设，这些假设都体现在继承代码中了。但是这些假设并不适合所有子类，因此子类中不得不大量地重定义（override）。只要在超类内做点修改，就可以减少许多重定义。在另一些地方，超类的某些意图并未被很好地理解，因此超类的有些行为在子类内重复了。还有一些地方，好几个子类做相同的事情，显然可以把这些代码移到类层次更上层去。.
这位顾问于是建议项目经理先查看并清理代码，但是经理似乎不以为然，毕竟程序看上去还能运行，而且项目面临的进度压力很大。于是经理只是说，过些时候再抽时间做。
顾问也把发现的情况告诉了开发这个类层次的程序员。程序员都很敏锐，看出了问题的严重性。他们知道这并不全是自己的错，有时候的确是旁观者清，当局者迷。因此程序员用了一两天清理类层次，完成时删掉了其中一半代码，而功能并未减少。他们对此十分满意，而且发现现在在类层次中加入新类或使用系统中其他的类更快也更容易了。
项目经理可不那么高兴。进度很紧，还有很多工作要做，这些程序员白白耗费两天时间，干的工作与系统几个月后要交付的多数功能毫无关系。原先的代码不是运行得很正常吗，而新设计不过就是纯了一点，清晰了一点。项目的目的是交付可以有效运行的代码，而不是要让一个学究满意。顾问接下来又建议应该类似地清理系统的其他核心部分，这会使整个项目停顿一两个星期。所有这些工作似乎只是为了让代码看起来更漂亮，而不能给系统添加任何新功能。
对这个故事你有什么感想？你认为这个顾问建议进一步清理程序对吗？或者你认为应该遵循那句古老的工程谚语：“如果能运行，就不要去修”？
我必须承认自己有偏见，因为我就是那个顾问。6个月之后这个项目宣告失败，很大的原因是代码太复杂了，无法调试，也无法达到可以接受的性能。
后来，另一个顾问Kent Beck受邀重启项目，几乎从头开始重写整个系统。他的许多做法都与众不同，其中最重要的就是坚持以重构持续不断地清理代码。这个项目的成功，以及重构在成功中扮演的角色，启发了我写作这本书，从而能够把Kent和其他人在使用重构改进软件质量中所获得的知识传播出去。
什么是重构
所谓重构是一种修改软件系统的过程，“它必须在不改变代码外在行为的情况下，改进程序的内部结构”。重构是一种训练有素、有条不紊的代码清理方式，需要尽量减少引入错误的机率，本质上，重构就是在编写代码之后再改进设计。
“在编写代码之后再改进设计”？这种说法真奇怪，按照目前对软件开发的理解，我们相信应该先设计而后编码。先有好的设计，然后才能开始编码。但是，随着时间流逝，代码在不断修改，于是系统的完整性、系统按原先设计所得的结构都逐渐减弱。代码慢慢腐化，编码也从工程沦为无章可循的乱来。
“重构”与这种做法正好相反。即使设计很糟糕，甚至一片混乱，你也可以通过重构将它改进为设计良好的代码。重构的每个步骤都很简单，甚至有些过分简单了：把某个字段（field）从一个类移到另一个类，把某些代码从一个方法（method）拉出来构成另一个方法，或是把一些代码在类层次中推上推下。但是，正所谓集腋成裘，这些小型修改的累积效应可以根本地改善设计。这和一般常见的“软件腐化”的观点恰恰相反。
通过重构，你可以找出改变的平衡点。你会发现设计不再是最先做出的，而是在开发过程中逐渐浮现出来。应该在构建系统的过程中学习如何改善设计。这种互动可以使一个程序的设计在开发过程中始终保持良好。
本书内容
本书是一本重构指南，针对职业程序员。我的目的是告诉你如何以一种可控且高效的方式进行重构。你将学会这样的重构方式：不在代码中引入错误，而是按部就班地改进结构。
按传统，书应该以一个简介开头。虽然我也同意这个原则，但是我发现概括地讨论或定义来介绍重构并不容易。所以我决定从一个实例开始。第l章给出一个含有一些常见设计缺陷的小程序，我把它重构为合格的面向对象程序。其间我们可以看到重构的过程，以及几个很有用的重构的具体应用。如果你想知道重构到底是怎么回事，这一章非常重要。
第2章讲述重构的一般性原则、定义以及进行重构的原因，还概略讨论了重构存在的一些问题。第3事由Kent Beck介绍如何寻找代码中的“坏味”（bad smell），以及如何运用重构清除这些坏味。“测试”在重构中扮演非常重要的角色，第4章介绍如何使用一个简单的开源Java测试框架，在代码中构建测试。
从第5章至第12章是本书的核心部分——重构目录。这不是一份全面的目录，只是一个起点，其中包括迄令为止我在工作中整理下来的所有重构。每当我想做点什么（例如Replace Conditional with Polymorphism）的时候，这份目录就会提醒我如何安全地循序前进。我希望这部分你日后会一再查阅。
本书介绍了其他人的许多研究成果，最后几章就是特邀他们之中的几位撰写的。Bill Opdyke在第13章记述了他在商业开发中应用重构技术遇到的一些问题。Don Roberts和John Brant在第14章展望了重构技术的未来——自动化工具，最后的总结（第15章）留给了重构技术的大师Kent Beck。
所用语言..
本书实例全部以Java编写。重构当然也可以在其他语言中使用，而且我也希望本书对其他语言的使用者也有用。但我觉得最好在本书中只使用Java，因为那是我最熟悉的语言。我会不时就如何在其他语言中进行重构添加一些提示，不过我真心希望其他人能以本书为基础针对其他语言写出更多重构书籍。
这位顾问于是建议项目经理先查看并清理代码，但是经理似乎不以为然，毕竟程序看上去还能运行，而且项目面临的进度压力很大。于是经理只是说，过些时候再抽时间做。
顾问也把发现的情况告诉了开发这个类层次的程序员。程序员都很敏锐，看出了问题的严重性。他们知道这并不全是自己的错，有时候的确是旁观者清，当局者迷。因此程序员用了一两天清理类层次，完成时删掉了其中一半代码，而功能并未减少。他们对此十分满意，而且发现现在在类层次中加入新类或使用系统中其他的类更快也更容易了。
项目经理可不那么高兴。进度很紧，还有很多工作要做，这些程序员白白耗费两天时间，干的工作与系统几个月后要交付的多数功能毫无关系。原先的代码不是运行得很正常吗，而新设计不过就是纯了一点，清晰了一点。项目的目的是交付可以有效运行的代码，而不是要让一个学究满意。顾问接下来又建议应该类似地清理系统的其他核心部分，这会使整个项目停顿一两个星期。所有这些工作似乎只是为了让代码看起来更漂亮，而不能给系统添加任何新功能。
对这个故事你有什么感想？你认为这个顾问建议进一步清理程序对吗？或者你认为应该遵循那句古老的工程谚语：“如果能运行，就不要去修”？
我必须承认自己有偏见，因为我就是那个顾问。6个月之后这个项目宣告失败，很大的原因是代码太复杂了，无法调试，也无法达到可以接受的性能。
后来，另一个顾问Kent Beck受邀重启项目，几乎从头开始重写整个系统。他的许多做法都与众不同，其中最重要的就是坚持以重构持续不断地清理代码。这个项目的成功，以及重构在成功中扮演的角色，启发了我写作这本书，从而能够把Kent和其他人在使用重构改进软件质量中所获得的知识传播出去。
什么是重构
所谓重构是一种修改软件系统的过程，“它必须在不改变代码外在行为的情况下，改进程序的内部结构”。重构是一种训练有素、有条不紊的代码清理方式，需要尽量减少引入错误的机率，本质上，重构就是在编写代码之后再改进设计。
“在编写代码之后再改进设计”？这种说法真奇怪，按照目前对软件开发的理解，我们相信应该先设计而后编码。先有好的设计，然后才能开始编码。但是，随着时间流逝，代码在不断修改，于是系统的完整性、系统按原先设计所得的结构都逐渐减弱。代码慢慢腐化，编码也从工程沦为无章可循的乱来。
“重构”与这种做法正好相反。即使设计很糟糕，甚至一片混乱，你也可以通过重构将它改进为设计良好的代码。重构的每个步骤都很简单，甚至有些过分简单了：把某个字段（field）从一个类移到另一个类，把某些代码从一个方法（method）拉出来构成另一个方法，或是把一些代码在类层次中推上推下。但是，正所谓集腋成裘，这些小型修改的累积效应可以根本地改善设计。这和一般常见的“软件腐化”的观点恰恰相反。
通过重构，你可以找出改变的平衡点。你会发现设计不再是最先做出的，而是在开发过程中逐渐浮现出来。应该在构建系统的过程中学习如何改善设计。这种互动可以使一个程序的设计在开发过程中始终保持良好。
本书内容
本书是一本重构指南，针对职业程序员。我的目的是告诉你如何以一种可控且高效的方式进行重构。你将学会这样的重构方式：不在代码中引入错误，而是按部就班地改进结构。
按传统，书应该以一个简介开头。虽然我也同意这个原则，但是我发现概括地讨论或定义来介绍重构并不容易。所以我决定从一个实例开始。第l章给出一个含有一些常见设计缺陷的小程序，我把它重构为合格的面向对象程序。其间我们可以看到重构的过程，以及几个很有用的重构的具体应用。如果你想知道重构到底是怎么回事，这一章非常重要。
第2章讲述重构的一般性原则、定义以及进行重构的原因，还概略讨论了重构存在的一些问题。第3事由Kent Beck介绍如何寻找代码中的“坏味”（bad smell），以及如何运用重构清除这些坏味。“测试”在重构中扮演非常重要的角色，第4章介绍如何使用一个简单的开源Java测试框架，在代码中构建测试。
从第5章至第12章是本书的核心部分——重构目录。这不是一份全面的目录，只是一个起点，其中包括迄令为止我在工作中整理下来的所有重构。每当我想做点什么（例如Replace Conditional with Polymorphism）的时候，这份目录就会提醒我如何安全地循序前进。我希望这部分你日后会一再查阅。
本书介绍了其他人的许多研究成果，最后几章就是特邀他们之中的几位撰写的。Bill Opdyke在第13章记述了他在商业开发中应用重构技术遇到的一些问题。Don Roberts和John Brant在第14章展望了重构技术的未来——自动化工具，最后的总结（第15章）留给了重构技术的大师Kent Beck。
所用语言..
本书实例全部以Java编写。重构当然也可以在其他语言中使用，而且我也希望本书对其他语言的使用者也有用。但我觉得最好在本书中只使用Java，因为那是我最熟悉的语言。我会不时就如何在其他语言中进行重构添加一些提示，不过我真心希望其他人能以本书为基础针对其他语言写出更多重构书籍。
序言
重构（refactoring）的概念出自Smalltalk界，但很快就进入了其他语言阵营。重构在框架开发中不可或缺，所以这个术语是框架开发人员在讨论自己的技艺时油然而生的。当他们改善自己的类层次结构时，当他们热烈讨论又可以删去多少行代码时，重构的概念就产生了。设计者知道，框架不可能第一次就完美无缺，它必须随着设计者的经验增长而改进；设计者也知道，阅读和修改代码的次数远远多于编写代码。要使代码易读、易修改，秘决就在于重构——对框架而言如此，对一般软件也如此。.
那么，重构有什么问题吗？简而言之，重构是有风险的。它要修改的是可以工作的程序，这可能引入一些微妙的错误。如果重构不当，可能使数天乃至数星期的工作前功尽弃。如果重构时有章不循、草率为之，风险将更大。开始深入自己的代码时，很快就会发现一些需要修改的地方，于是你更加深入。探究越深，找到的重构机会就越多……于是修改也越多。最后你挖了一个大坑，自己却爬不出去了。为了避免自掘坟墓，重构必须按部就班地进行。我和合著者写《设计模式》一书时曾提到：设计模式为重构提供了目标。然而“确定目标”只是问题之一，转换程序达到目标，是另一个难题。..
Martin Fowler和本书另几位作者清楚阐述了重构过程，他们为面向对象软件开发做出了重大贡献。本书解释了重构的原理和最佳实践，并指出在什么场合应该开始深入研究代码，进行改进。本书的核心部分是一个完整的重构目录，其中每一个重构都介绍了一种经过验证的代码转换的动机和做法。某些重构，如Extract Method和Move Field乍看起来显而易见，但切不可掉以轻心，因为理解这种重构的做法正是有条不紊地进行重构的关键。本书中的重构将帮助你每次一小步地修改代码，从而减少了设计修改过程中的风险。很快，这些重构的名字就会成为你日常的开发词汇。
我第一次体验严格的、每次一小步的重构，是在30 000英尺高空与Kent Beck进行结对编程（pair-programming） 。我们应用本书中的重构，每次只走一步。最后，我对这种实践方式的效果感到十分惊讶。我不但对最后结果更有信心，而且感到开发时自己的压力也小了很多。所以，我强烈推荐你尝试这些重构，你的生活和你的程序都将因此更美好。...
——Erich Gamma
那么，重构有什么问题吗？简而言之，重构是有风险的。它要修改的是可以工作的程序，这可能引入一些微妙的错误。如果重构不当，可能使数天乃至数星期的工作前功尽弃。如果重构时有章不循、草率为之，风险将更大。开始深入自己的代码时，很快就会发现一些需要修改的地方，于是你更加深入。探究越深，找到的重构机会就越多……于是修改也越多。最后你挖了一个大坑，自己却爬不出去了。为了避免自掘坟墓，重构必须按部就班地进行。我和合著者写《设计模式》一书时曾提到：设计模式为重构提供了目标。然而“确定目标”只是问题之一，转换程序达到目标，是另一个难题。..
Martin Fowler和本书另几位作者清楚阐述了重构过程，他们为面向对象软件开发做出了重大贡献。本书解释了重构的原理和最佳实践，并指出在什么场合应该开始深入研究代码，进行改进。本书的核心部分是一个完整的重构目录，其中每一个重构都介绍了一种经过验证的代码转换的动机和做法。某些重构，如Extract Method和Move Field乍看起来显而易见，但切不可掉以轻心，因为理解这种重构的做法正是有条不紊地进行重构的关键。本书中的重构将帮助你每次一小步地修改代码，从而减少了设计修改过程中的风险。很快，这些重构的名字就会成为你日常的开发词汇。
我第一次体验严格的、每次一小步的重构，是在30 000英尺高空与Kent Beck进行结对编程（pair-programming） 。我们应用本书中的重构，每次只走一步。最后，我对这种实践方式的效果感到十分惊讶。我不但对最后结果更有信心，而且感到开发时自己的压力也小了很多。所以，我强烈推荐你尝试这些重构，你的生活和你的程序都将因此更美好。...
——Erich Gamma
