（已有5条评价）基本信息
- 原书名：Refactoring: Improving the Design of Existing Code
- 原出版社： Addison-Wesley Professional
- 作者： (美)Martin Fowler
- 丛书名： 图灵程序设计丛书 软件工程系列
- 出版社：人民邮电出版社
- ISBN：9787115239143
- 上架时间：2010-11-4
- 出版日期：2010 年11月
- 开本：16开
- 页码：431
- 版次：1-1
- 所属分类：计算机 > 软件工程及软件方法学 > 综合
计算机 > 软件与程序设计 > 综合 > 程序(设计)理论
编辑推荐
软件开发的不朽经典
生动阐述重构原理和具体做法
普通程序员进阶到编程高手必须修炼的秘笈
内容简介
作译者
Martin Fowler是一位独立咨询顾问，他运用对象技术解决企业问题已经超过十年。他的顾问领域包括健康管理、金融贸易，以及法人财务。他的客户包括Chrysler，Citibank，UK National Health Service，AndersenConsulting，NetscapeCommunications。此外Fowler也是objects、UML、patterns技术的一位合格讲师，他是《AnalysisPatterns》和《UML Distilled》的作者。
目录
Chapter 1: Refactoring, a First Example 1[BR] The Starting Point 1[BR] The First Step in Refactoring 7[BR] Decomposing and Redistributing the Statement Method 8[BR] Replacing the Conditional Logic on Price Code with Polymorphism 34[BR] Final Thoughts 52[BR]Chapter 2: Principles in Refactoring 53[BR] Defining Refactoring 53[BR] Why Should You Refactor 55[BR] When Should You Refactor 57[BR] What Do I Tell My Manager 60[BR] Problems with Refactoring 62[BR] Refactoring and Design 66[BR] Refactoring and Performance 69[BR] Where Did Refactoring Come From 71[BR]Chapter 3: Bad Smells in Code (by Kent Beck and Martin Fowler) 75[BR] Duplicated Code 76[BR] Long Method 76[BR] Large Class 78[BR] Long Parameter List 78[BR] Divergent Change 79[BR] Shotgun Surgery 80[BR] Feature Envy 80[BR] Data Clumps 81[BR] Primitive Obsession 81[BR] Switch Statements 82[BR] Parallel Inheritance Hierarchies 83[BR] Lazy Class 83[BR] Speculative Generality 83[BR] Temporary Field 84[BR] Message Chains 84[BR] Middle Man 85[BR] Inappropriate Intimacy 85[BR] Alternative Classes with Different Interfaces 85[BR] Incomplete Library Class 86[BR] Data Class 86[BR] Refused Bequest 87[BR] Comments 87[BR]Chapter 4: Building Tests 89[BR] The Value of Self-testing Code 89[BR] The JUnit Testing Framework 91[BR] Adding More Tests 97[BR]Chapter 5: Toward a Catalog of Refactorings 103[BR] Format of the Refactorings 103[BR] Finding References 105[BR] How Mature Are These Refactorings 106[BR]Chapter 6: Composing Methods 109[BR] Extract Method 110[BR] Inline Method 117[BR] Inline Temp 119[BR] Replace Temp with Query 120[BR] Introduce Explaining Variable 124[BR] Split Temporary Variable 128[BR] Remove Assignments to Parameters 131[BR] Replace Method with Method Object 135[BR] Substitute Algorithm 139[BR]Chapter 7: Moving Features Between Objects 141[BR] Move Method 142[BR] Move Field 146[BR] Extract Class 149[BR] Inline Class 154[BR] Hide Delegate 157[BR] Remove Middle Man 160[BR] Introduce Foreign Method 162[BR] Introduce Local Extension 164[BR]Chapter 8: Organizing Data 169[BR] Self Encapsulate Field 171[BR] Replace Data Value with Object 175[BR] Change Value to Reference 179[BR] Change Reference to Value 183[BR] Replace Array with Object 186[BR] Duplicate Observed Data 189[BR] Change Unidirectional Association to Bidirectional 197[BR] Change Bidirectional Association to Unidirectional 200[BR] Replace Magic Number with Symbolic Constant 204[BR] Encapsulate Field 206[BR] Encapsulate Collection 208[BR] Replace Record with Data Class 217[BR] Replace Type Code with Class 218[BR] Replace Type Code with Subclasses 223[BR] Replace Type Code with State/Strategy 227[BR] Replace Subclass with Fields 232[BR]Chapter 9: Simplifying Conditional Expressions 237[BR] Decompose Conditional 238[BR] Consolidate Conditional Expression 240[BR] Consolidate Duplicate Conditional Fragments 243[BR] Remove Control Flag 245[BR] Replace Nested Conditional with Guard Clauses 250[BR] Replace Conditional with Polymorphism 255[BR] Introduce Null Object 260[BR] Introduce Assertion 267[BR]Chapter 10: Making Method Calls Simpler 271[BR] Rename Method 273[BR] Add Parameter 275[BR] Remove Parameter 277[BR] Separate Query from Modifier 279[BR] Parameterize Method 283[BR] Replace Parameter with Explicit Methods 285[BR] Preserve Whole Object 288[BR] Replace Parameter with Method 292[BR] Introduce Parameter Object 295[BR] Remove Setting Method 300[BR] Hide Method 303[BR] Replace Constructor with Factory Method 304[BR] Encapsulate Downcast 308[BR] Replace Error Code with Exception 310[BR] Replace Exception with Test 315[BR]Chapter 11: Dealing with Generalization 319[BR] Pull Up Field 320[BR] Pull Up Method 322[BR] Pull Up Constructor Body 325[BR] Push Down Method 328[BR] Push Down Field 329[BR] Extract Subclass 330[BR] Extract Superclass 336[BR] Extract Interface 341[BR] Collapse Hierarchy 344[BR] Form Template Method 345[BR] Replace Inheritance with Delegation 352[BR] Replace Delegation with Inheritance 355[BR]Chapter 12: Big Refactorings (by Kent Beck and Martin Fowler) 359[BR] Tease Apart Inheritance 362[BR] Convert Procedural Design to Objects 368[BR] Separate Domain from Presentation 370[BR] Extract Hierarchy 375[BR]Chapter 13: Refactoring, Reuse, and Reality (by William Opdyke) 379[BR] A Reality Check 380[BR] Why Are Developers Reluctant to Refactor Their Programs 381[BR] A Reality Check (Revisited) 394[BR] Resources and References for Refactoring 394[BR] Implications Regarding Software Reuse and Technology Transfer 395[BR] A Final Note 397[BR] References 397[BR]Chapter 14: Refactoring Tools (by Don Roberts and John Brant) 401[BR] Refactoring with a Tool 401[BR] Technical Criteria for a Refactoring Tool 403[BR] Practical Criteria for a Refactoring Tool 405[BR] Wrap Up 407[BR]Chapter 15: Putting It All Together (by Kent Beck) 409[BR]References 413[BR]List of Soundbites 417[BR]Index 419
前言
从前，有位咨询顾问造访客户调研其开发项目。系统核心是个类继承体系，顾问看了开发人员所写的一些代码。他发现整个体系相当凌乱，上层超类对于系统的运作做了一些假设，下层子类实现这些假设。但是这些假设并不适合所有子类，导致覆写（override）工作非常繁重。只要在超类做点修改，就可以减少许多覆写工作。在另一些地方，超类的某些意图并未被良好理解，因此其中某些行为在子类内重复出现。还有一些地方，好几个子类做相同的事情，其实可以把它们搬到继承体系的上层去做。
这位顾问于是建议项目经理看看这些代码，把它们整理一下，但是经理并不热衷于此，毕竟程序看上去还可以运行，而且项目面临很大的进度压力。于是经理说，晚些时候再抽时间做这些整理工作。
顾问也把他的想法告诉了在这个继承体系上工作的程序员，告诉他们可能发生的事情。程序员都很敏锐，马上就看出问题的严重性。他们知道这并不全是他们的错，有时候的确需要借助外力才能发现问题。程序员立刻用了一两天的时间整理好这个继承体系，并删掉了其中一半代码，功能毫发无损。他们对此十分满意，而且发现在继承体系中加入新的类或使用系统中的其他类都更快、更容易了。
项目经理并不高兴。进度排得很紧，有许多工作要做。系统必须在几个月之后发布，而这些程序员却白白耗费了两天时间，干的工作与要交付的多数功能毫无关系。原先的代码运行起来还算正常，他们的新设计看来有点过于追求完美。项目要交付给客户的，是可以有效运行的代码，不是用以取悦学究的完美东西。顾问接下来又建议应该在系统的其他核心部分进行这样的整理工作，这会使整个项目停顿一至二个星期。所有这些工作只是为了让代码看起来更漂亮，并不能给系统添加任何新功能。
你对这个故事有什么感想？你认为这个顾问的建议（更进一步整理程序）是对的吗？你会遵循那句古老的工程谚语吗：“如果它还可以运行，就不要动它。”
我必须承认自己有某些偏见，因为我就是那个顾问。六个月之后这个项目宣告失败，很大的原因是代码太复杂，无法调试，也无法获得可被接受的性能。
后来，项目重新启动，几乎从头开始编写整个系统，Kent Beck受邀做了顾问。他做了几件迥异以往的事，其中最重要的一件就是坚持以持续不断的重构行为来整理代码。这个项目的成功，以及重构在这个成功项目中扮演的角色，启发了我写这本书，如此一来我就能够把Kent和其他一些人已经学会的“以重构方式改进软件质量”的知识，传播给所有读者。
什么是重构
所谓重构（refactoring）是这样一个过程：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。重构是一种经千锤百炼形成的有条不紊的程序整理方法，可以最大限度地减少整理过程中引入错误的几率。本质上说，重构就是在代码写好之后改进它的设计。
“在代码写好之后改进它的设计”?这种说法有点奇怪。按照目前对软件开发的理解，我们相信应该先设计而后编码：首先得有一个良好的设计，然后才能开始编码。但是，随着时间流逝，人们不断修改代码，于是根据原先设计所得的系统，整体结构逐渐衰弱。代码质量慢慢沉沦，编码工作从严谨的工程堕落为胡砍乱劈的随性行为。
“重构”正好与此相反。哪怕你手上有一个糟糕的设计，甚至是一堆混乱的代码，你也可以借由重构将它加工成设计良好的代码。重构的每个步骤都很简单，甚至显得有些过于简单：你只需要把某个字段从一个类移到另一个类，把某些代码从一个函数拉出来构成另一个函数，或是在继承体系中把某些代码推上推下就行了。但是，聚沙成塔，这些小小的修改累积起来就可以根本改善设计质量。这和一般常见的“软件会慢慢腐烂”的观点恰恰相反。
通过重构，你可以找出改变的平衡点。你会发现所谓设计不再是一切动作的前提，而是在整个开发过程中逐渐浮现出来。在系统构筑过程中，你可以学习如何强化设计，其间带来的互动可以让一个程序在开发过程中持续保有良好的设计。
本书有什么
本书是一本为专业程序员而写的重构指南。我的目的是告诉你如何以一种可控制且高效率的方式进行重构。你将学会如何有条不紊地改进程序结构，而且不会引入错误，这就是正确的重构方式。
按照传统，图书应该以引言开头。尽管我也同意这个原则，但是我发现以概括性的讨论或定义来介绍重构，实在不是件容易的事。所以我决定用一个实例做为开路先锋。第1章展示了一个小程序，其中有些常见的设计缺陷，我把它重构为更合格的面向对象程序。其间我们可以看到重构的过程，以及几个很有用的重构手法。如果你想知道重构到底是怎么回事，这一章不可不读。
第2章讨论重构的一般性原则、定义，以及进行重构的原因，我也大致介绍了重构所存在的一些问题。第3章由Kent Beck介绍如何嗅出代码中的“坏味道”，以及如何运用重构清除这些坏味道。测试在重构中扮演着非常重要的角色，第4章介绍如何运用一个简单而且开源的Java测试框架，在代码中构筑测试环境。
本书的核心部分——重构列表——从第5章延伸至第12章。它不能说是一份全面的列表，只是一个起步，其中包括迄今为止我在工作中整理下来的所有重构手法。每当我想做点什么——例如Replace Conditional with Polymorphism (255) ——的时候，这份列表就会提醒我如何一步一步安全前进。我希望这是值得你日后一再回顾的部分。
本书介绍了其他人的许多研究成果，最后几章就是由他们之中的几位所客串写就的。Bill Opdyke在第13章记述他将重构技术应用于商业开发过程中遇到的一些问题。Don Roberts和John Brant在第14章展望重构技术的未来——自动化工具。我把最后一章（第15章）留给重构技术的顶尖大师Kent Beck来压轴。
在Java中运用重构
本书范例全部使用Java撰写。重构当然也可以在其他语言中实现，而且我也希望这本书能够给其他语言使用者带来帮助。但我觉得我最好在本书中只使用Java，因为那是我最熟悉的语言。我会不时写下一些提示，告诉读者如何在其他语言中进行重构，不过我真心希望看到其他人在本书基础上针对其他语言写出更多重构方面的书籍。
这位顾问于是建议项目经理看看这些代码，把它们整理一下，但是经理并不热衷于此，毕竟程序看上去还可以运行，而且项目面临很大的进度压力。于是经理说，晚些时候再抽时间做这些整理工作。
顾问也把他的想法告诉了在这个继承体系上工作的程序员，告诉他们可能发生的事情。程序员都很敏锐，马上就看出问题的严重性。他们知道这并不全是他们的错，有时候的确需要借助外力才能发现问题。程序员立刻用了一两天的时间整理好这个继承体系，并删掉了其中一半代码，功能毫发无损。他们对此十分满意，而且发现在继承体系中加入新的类或使用系统中的其他类都更快、更容易了。
项目经理并不高兴。进度排得很紧，有许多工作要做。系统必须在几个月之后发布，而这些程序员却白白耗费了两天时间，干的工作与要交付的多数功能毫无关系。原先的代码运行起来还算正常，他们的新设计看来有点过于追求完美。项目要交付给客户的，是可以有效运行的代码，不是用以取悦学究的完美东西。顾问接下来又建议应该在系统的其他核心部分进行这样的整理工作，这会使整个项目停顿一至二个星期。所有这些工作只是为了让代码看起来更漂亮，并不能给系统添加任何新功能。
你对这个故事有什么感想？你认为这个顾问的建议（更进一步整理程序）是对的吗？你会遵循那句古老的工程谚语吗：“如果它还可以运行，就不要动它。”
我必须承认自己有某些偏见，因为我就是那个顾问。六个月之后这个项目宣告失败，很大的原因是代码太复杂，无法调试，也无法获得可被接受的性能。
后来，项目重新启动，几乎从头开始编写整个系统，Kent Beck受邀做了顾问。他做了几件迥异以往的事，其中最重要的一件就是坚持以持续不断的重构行为来整理代码。这个项目的成功，以及重构在这个成功项目中扮演的角色，启发了我写这本书，如此一来我就能够把Kent和其他一些人已经学会的“以重构方式改进软件质量”的知识，传播给所有读者。
什么是重构
所谓重构（refactoring）是这样一个过程：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。重构是一种经千锤百炼形成的有条不紊的程序整理方法，可以最大限度地减少整理过程中引入错误的几率。本质上说，重构就是在代码写好之后改进它的设计。
“在代码写好之后改进它的设计”?这种说法有点奇怪。按照目前对软件开发的理解，我们相信应该先设计而后编码：首先得有一个良好的设计，然后才能开始编码。但是，随着时间流逝，人们不断修改代码，于是根据原先设计所得的系统，整体结构逐渐衰弱。代码质量慢慢沉沦，编码工作从严谨的工程堕落为胡砍乱劈的随性行为。
“重构”正好与此相反。哪怕你手上有一个糟糕的设计，甚至是一堆混乱的代码，你也可以借由重构将它加工成设计良好的代码。重构的每个步骤都很简单，甚至显得有些过于简单：你只需要把某个字段从一个类移到另一个类，把某些代码从一个函数拉出来构成另一个函数，或是在继承体系中把某些代码推上推下就行了。但是，聚沙成塔，这些小小的修改累积起来就可以根本改善设计质量。这和一般常见的“软件会慢慢腐烂”的观点恰恰相反。
通过重构，你可以找出改变的平衡点。你会发现所谓设计不再是一切动作的前提，而是在整个开发过程中逐渐浮现出来。在系统构筑过程中，你可以学习如何强化设计，其间带来的互动可以让一个程序在开发过程中持续保有良好的设计。
本书有什么
本书是一本为专业程序员而写的重构指南。我的目的是告诉你如何以一种可控制且高效率的方式进行重构。你将学会如何有条不紊地改进程序结构，而且不会引入错误，这就是正确的重构方式。
按照传统，图书应该以引言开头。尽管我也同意这个原则，但是我发现以概括性的讨论或定义来介绍重构，实在不是件容易的事。所以我决定用一个实例做为开路先锋。第1章展示了一个小程序，其中有些常见的设计缺陷，我把它重构为更合格的面向对象程序。其间我们可以看到重构的过程，以及几个很有用的重构手法。如果你想知道重构到底是怎么回事，这一章不可不读。
第2章讨论重构的一般性原则、定义，以及进行重构的原因，我也大致介绍了重构所存在的一些问题。第3章由Kent Beck介绍如何嗅出代码中的“坏味道”，以及如何运用重构清除这些坏味道。测试在重构中扮演着非常重要的角色，第4章介绍如何运用一个简单而且开源的Java测试框架，在代码中构筑测试环境。
本书的核心部分——重构列表——从第5章延伸至第12章。它不能说是一份全面的列表，只是一个起步，其中包括迄今为止我在工作中整理下来的所有重构手法。每当我想做点什么——例如Replace Conditional with Polymorphism (255) ——的时候，这份列表就会提醒我如何一步一步安全前进。我希望这是值得你日后一再回顾的部分。
本书介绍了其他人的许多研究成果，最后几章就是由他们之中的几位所客串写就的。Bill Opdyke在第13章记述他将重构技术应用于商业开发过程中遇到的一些问题。Don Roberts和John Brant在第14章展望重构技术的未来——自动化工具。我把最后一章（第15章）留给重构技术的顶尖大师Kent Beck来压轴。
在Java中运用重构
本书范例全部使用Java撰写。重构当然也可以在其他语言中实现，而且我也希望这本书能够给其他语言使用者带来帮助。但我觉得我最好在本书中只使用Java，因为那是我最熟悉的语言。我会不时写下一些提示，告诉读者如何在其他语言中进行重构，不过我真心希望看到其他人在本书基础上针对其他语言写出更多重构方面的书籍。
序言
“重构”这个概念来自Smalltalk圈子，没多久就进入了其他语言阵营之中。由于重构是框架开发中不可缺少的一部分，所以当框架开发人员讨论自己的工作时，这个术语就诞生了。当他们精练自己的类继承体系时，当他们叫喊自己可以拿掉多少多少行代码时，重构的概念慢慢浮出水面。框架设计者知道，这东西不可能一开始就完全正确，它将随着设计者的经验成长而进化；他们也知道，代码被阅读和被修改的次数远远多于它被编写的次数。保持代码易读、易修改的关键，就是重构——对框架而言如此，对一般软件也如此。
好极了，还有什么问题吗？问题很显然：重构具有风险。它必须修改运作中的程序，这可能引入一些不易察觉的错误。如果重构方式不恰当，可能毁掉你数天甚至数星期的成果。如果重构时不做好准备，不遵守规则，风险就更大。你挖掘自己的代码，很快发现了一些值得修改的地方，于是你挖得更深。挖得愈深，找到的重构机会就越多，于是你的修改也愈多……最后你给自己挖了个大坑，却爬不出去了。为了避免自掘坟墓，重构必须系统化进行。我在《设计模式》书中和另外三位作者曾经提过：设计模式为重构提供了目标。然而“确定目标”只是问题的一部分而已，改造程序以达到目标，是另一个难题。
Martin Fowler和本书另几位作者清楚揭示了重构过程，他们为面向对象软件开发所做的贡献难以衡量。本书解释了重构的原理和最佳实践，并指出何时何地你应该开始挖掘你的代码以求改善。本书的核心是一系列完整的重构方法，其中每一项都介绍一种经过实践检验的代码变换手法的动机和技术。某些项目如Extract Method和Move Field看起来可能很浅显，但不要掉以轻心，因为理解这类技术正是有条不紊地进行重构的关键。本书所提的这些重构手法将帮助你一次一小步地修改你的代码，这就减少了过程中的风险。很快你就会把这些重构手法和其名称加入自己的开发词典中，并且朗朗上口。
我第一次体验有讲究的、一次一小步的重构，是某次与Kent Beck在30 000英尺高空的飞行旅途中结对编程。我们运用本书收录的重构手法，保证每次只走一步。最后，我对这种实践方式的效果感到十分惊讶。我不但对最后结果更有信心，而且开发压力也小了很多。所以，我极力推荐你试试这些重构手法，你和你的程序都将因此更美好。
Erich Gamma
《设计模式》第一作者，Eclipse平台主架构师
好极了，还有什么问题吗？问题很显然：重构具有风险。它必须修改运作中的程序，这可能引入一些不易察觉的错误。如果重构方式不恰当，可能毁掉你数天甚至数星期的成果。如果重构时不做好准备，不遵守规则，风险就更大。你挖掘自己的代码，很快发现了一些值得修改的地方，于是你挖得更深。挖得愈深，找到的重构机会就越多，于是你的修改也愈多……最后你给自己挖了个大坑，却爬不出去了。为了避免自掘坟墓，重构必须系统化进行。我在《设计模式》书中和另外三位作者曾经提过：设计模式为重构提供了目标。然而“确定目标”只是问题的一部分而已，改造程序以达到目标，是另一个难题。
Martin Fowler和本书另几位作者清楚揭示了重构过程，他们为面向对象软件开发所做的贡献难以衡量。本书解释了重构的原理和最佳实践，并指出何时何地你应该开始挖掘你的代码以求改善。本书的核心是一系列完整的重构方法，其中每一项都介绍一种经过实践检验的代码变换手法的动机和技术。某些项目如Extract Method和Move Field看起来可能很浅显，但不要掉以轻心，因为理解这类技术正是有条不紊地进行重构的关键。本书所提的这些重构手法将帮助你一次一小步地修改你的代码，这就减少了过程中的风险。很快你就会把这些重构手法和其名称加入自己的开发词典中，并且朗朗上口。
我第一次体验有讲究的、一次一小步的重构，是某次与Kent Beck在30 000英尺高空的飞行旅途中结对编程。我们运用本书收录的重构手法，保证每次只走一步。最后，我对这种实践方式的效果感到十分惊讶。我不但对最后结果更有信心，而且开发压力也小了很多。所以，我极力推荐你试试这些重构手法，你和你的程序都将因此更美好。
Erich Gamma
《设计模式》第一作者，Eclipse平台主架构师
媒体评论
“这本书之于重构就相当于韵谱之于作诗。一个翻着韵书作诗的诗人一定是蹩脚的，但好的诗人却要对那109个韵部了然于胸；同样，一个好的程序员要求能够主动自然地重构代码，虽不应翻着重构手册干活，但需对本书中提到的70多个重构方法成竹在胸。然而，在达到这一境界之前，需要不断的实践和经验积累，并且要先读读Fowler的这本书。”
“一口气读完了这本书，感觉书中作者对代码的整理不像是一种技术，更像是一种艺术。”
“太经典了，看这本书真有醍醐灌顶的感觉。”
“处于金字塔顶部的书不多，而这一本书恰恰就是，很幸运我看到了它。”
“这本书本质上是向我们推荐了一种优秀的编程习惯和编程态度。在领会本书思想的同时，我们也应该培养一种精益求精的工作态度，探索一条更适合自己的重构道路。”
“今年已经看了两遍，每次都有很大的收获。特别喜欢其中对其他章节的索引，当你把它作为一个手边随时翻阅的参考书看时，它不知不觉引导你读了很多内容，问题也在不知不觉中有了求解思路，最终得以解决。”
“不要写完代码就束之高阁，适当地优化代码结构，能够为以后的开发带来许多方便，这本书就向你介绍了这方面的技巧，说得非常详细。”
“程序几乎离不开重构，但如何更加迅速有效地重构却一直没有系统性的指导。本书就是这样的经典巨著，有了它，重构不再烦琐！”
“一口气读完了这本书，感觉书中作者对代码的整理不像是一种技术，更像是一种艺术。”
“太经典了，看这本书真有醍醐灌顶的感觉。”
“处于金字塔顶部的书不多，而这一本书恰恰就是，很幸运我看到了它。”
“这本书本质上是向我们推荐了一种优秀的编程习惯和编程态度。在领会本书思想的同时，我们也应该培养一种精益求精的工作态度，探索一条更适合自己的重构道路。”
“今年已经看了两遍，每次都有很大的收获。特别喜欢其中对其他章节的索引，当你把它作为一个手边随时翻阅的参考书看时，它不知不觉引导你读了很多内容，问题也在不知不觉中有了求解思路，最终得以解决。”
“不要写完代码就束之高阁，适当地优化代码结构，能够为以后的开发带来许多方便，这本书就向你介绍了这方面的技巧，说得非常详细。”
“程序几乎离不开重构，但如何更加迅速有效地重构却一直没有系统性的指导。本书就是这样的经典巨著，有了它，重构不再烦琐！”
