重构－改善既有代码的设计（中文版） (2008 年度畅销榜NO.4 )

译序by侯捷
译序by熊节
序言（Foreword）by Erich Gamma xiii
前言（Preface）by Martin Fowler
什么是重构（Refactoring）？ xvi
本书有些什么？ xvii
谁该阅读本书？ xviii
站在前人的肩膀上 xix
致谢 xix
第1章：重构，第一个案例（Refactoring, a First Example） 1
1.1起点 2
1.2重构的第一步 7
1.3分解并重组Statement() 8
1.4运用多态（polymorphism）取代与价格相关的条件逻辑 34
1.5结语 52
第2章：重构原则（Principles in Refactoring） 53
2.1何谓重构？ 53
2.2为何重构？ 55
2.3何时重构？ 57
2.4怎么对经理说？ 60
2.5重构的难题 62
2.6重构与设计 66
2.7重构与性能（Performance） 69
2.8重构起源何处？ 71
第3章：代码的坏味道（Bad Smells in Code, by Kent Beck and Martin Fowler） 75
3.1 Duplicated Code（重复的代码） 76
3.2 Long Method（过长函数） 76
3.3 Large Class（过大类） 78
3.4 Long Parameter List（过长参数列） 78
3.5 Divergent Change（发散式变化） 79
3.6 Shortgun Surgery（霰弹式修改） 80
3.7 Feature Envy（依恋情结） 80
3.8 Data Clumps（数据泥团） 81
3.9 Primitive Obsession（基本型别偏执） 81
3.10 Switch Statements（switch惊悚现身） 82
3.11 Parallel Inheritance Hierarchies（平行继承体系） 83
3.12 Lazy Class（冗赘类） 83
3.13 Speculative Generality（夸夸其谈未来性） 83
3.14 Temporary Field（令人迷惑的暂时值域） 84
3.15 Message Chains（过度耦合的消息链） 84
3.16 Middle Man（中间转手人） 85
3.17 Inappropriate Intimacy（狎昵关系） 85
3.18 Alternative Classes with Different Interfaces（异曲同工的类） 85
3.19 Incomplete Library Class（不完善的程序库类） 86
3.20 Data Class（纯稚的数据类） 86
3.21 Refused Bequest（被拒绝的遗赠） 87
3.22 Comments（过多的注释） 87
第4章：建立测试体系（Building Tests） 89
4.1自我测试码（Self-testing Code）的价值 89
4.2 JUnit测试框架（Testing Framework） 91
4.3添加更多测试 97
第5章：重构名录（Toward a Catalog of Refactoring） 103
5.1重构的记录格式（Format of Refactorings） 103
5.2寻找引用点（Finding References） 105
5.3这些重构准则有多成熟？ 106
第6章：重新组织你的函数（Composing Methods） 109
6.1 Extract Method（提炼函数） 110
6.2 Inline Method（将函数内联化） 117
6.3 Inline Temp（将临时变量内联化） 119
6.4 Replace Temp With Query（以查询取代临时变量） 120
6.5 Introduce Explaining Variable（引入解释性变量） 124
6.6 Split Temporary Variable（剖解临时变量） 128
6.7 Remove Assignments to Parameters（移除对参数的赋值动作） 131
6.8 Replace Method with Method Object（以函数对象取代函数） 135
6.9 Substitute Algorithm（替换你的算法） 139
第7章：在对象之间移动特性（Moving Features Between Objects） 141
7.1 Move Method（搬移函数） 142
7.2 Move Field（搬移值域） 146
7.3 Extract Class（提炼类） 149
7.4 Inline Class（将类内联化） 154
7.5 Hide Delegate（隐藏「委托关系」） 157
7.6 Remove Middle Man（移除中间人） 160
7.7 Introduce Foreign Method（引入外加函数） 162
7.8 Introduce Local Extension（引入本地扩展） 164
第8章：重新组织你的数据（Organizing Data） 169
8.1 Self Encapsulate Field（自封装值域） 171
8.2 Replace Data Value with Object（以对象取代数据值） 175
8.3 Change Value to Reference（将实值对象改为引用对象） 179
8.4 Change Reference to Value（将引用对象改为实值对象） 183
8.5 Replace Array with Object（以对象取代数组） 186
8.6 Duplicate Observed Data（复制「被监视数据」） 189
8.7 Change Unidirectional Association to Bidirectional 197
（将单向关联改为双向）
8.8 Change Bidirectional Association to Unidirectional 200
（将双向关联改为单向）
8.9 Replace Magic Number with Symbolic Constant 204
（以符号常量/字面常量 取代魔法数）
8.10 Encapsulate Field（封装值域） 206
8.11 Encapsulate Collection（封装群集） 208
8.12 Replace Record with Data Class（以数据类取代记录） 217
8.13 Replace Type Code with Class（以类取代型别码） 218
8.14 Replace Type Code with Subclasses 223
（以子类取代型别码）
8.15 Replace Type Code with State/Strategy 227
（以State/Strategy取代型别码）
8.16 Replace Subclass with Fields（以值域取代子类） 232
第9章：简化条件表达式（Simplifying Conditional Expressions） 237
9.1 Decompose Conditional（分解条件式） 238
9.2 Consolidate Conditional Expression（合并条件式） 240
9.3 Consolidate Duplicate Conditional Fragments 243
（合并重复的条件片段）
9.4 Remove Control Flag（移除控制标记） 245
9.5 Replace Nested Conditional with Guard Clauses 250
（以卫语句取代嵌套条件式）
9.6 Replace Conditional with Polymorphism（以多态取代条件式） 255
9.7 Introduce Null Object（引入Null对象） 260
9.8 Introduce Assertion（引入断言） 267
第10章：简化函数呼叫（Making Method Calls Simpler） 271
10.1 Rename Method（重新命名函数） 273
10.2 Add Parameter（添加参数） 275
10.3 Remove Parameter（移除参数） 277
10.4 Separate Query from Modifier（将查询函数和修改函数分离） 279
10.5 Parameterize Method（令函数携带参数） 283
10.6 Replace Parameter with Explicit Methods（以明确函数取代参数）285
10.7 Preserve Whole Object（保持对象完整） 288
10.8 Replace Parameter with Method（以函数取代参数） 292
10.9 Introduce Parameter Object（引入参数对象） 295
10.10 Remove Setting Method（移除设值函数） 300
10.11 Hide Method（隐藏你的函数） 303
10.12 Replace Constructor with Factory Method（以工厂方法取代构造函数）304
10.13 Encapsulate Downcast（封装「向下转型」动作） 308
10.14 Replace Error Code with Exception（以异常取代错误码） 310
10.15 Replace Exception with Test（以测试取代异常） 315
第11章：处理概括关系（Dealing with Generalization） 319
11.1 Pull Up Field（值域上移） 320
11.2 Pull Up Method（函数上移） 322
11.3 Pull Up Constructor Body（构造函数本体上移） 325
11.4 Push Down Method（函数下移） 328
11.5 Push Down Field（值域下移） 329
11.6 Extract Subclass（提炼子类） 330
11.7 Extract Superclass（提炼超类） 336
11.8 Extract Interface（提炼接口） 341
11.9 Collapse Hierarchy（折叠继承体系） 344
11.10 Form Template Method（塑造模板函数） 345
11.11 Replace Inheritance with Delegation（以委托取代继承） 352
11.12 Replace Delegation with Inheritance（以继承取代委托） 355
第12章：大型重构（Big Refactorings, by Kent Beck and Martin Fowler） 359
12.1 Tease Apart Inheritance（疏理并分解继承体系） 362
12.2 Convert Procedural Design to Objects 368
（将过程化设计转化为对象设计）
12.3 Separate Domain from Presentation（将领域和表述/显示分离） 370
12.4 Extract Hierarchy（提炼继承体系） 375
第13章：重构, 复用, 与现实 379
（Refactoring, Reuse, and Reality, by William Opdyke）
13.1现实的检验 380
13.2为什么开发者不愿意重构他们的程序？ 381
13.3现实的检验（再论） 394
13.4重构的资源和参考数据 394
13.5从重构联想到软件复用和技术传播 395
13.6结语 397
13.7参考文献 397
第14章：重构工具（Refactoring Tools, by Don Roberts and John Brant） 401
14.1使用工具进行重构 401
14.2重构工具的技术标准（Technical Criteria） 403
14.3重构工具的实用标准（Practical Criteria） 405
14.4小结 407
第15章：集成（Put It All Together, by Kent Beck） 409
参考书目（References） 413
原音重现（List of Soundbites） 417
索引

看过铁路道班工人吗？提着手持式砸道机，机身带着钝钝扁扁的钻头，在铁道上、枕木间卖力地「砍劈钻凿」。他们在做什麽？他们在使路基上的碎石块（道碴）因持续剧烈的震动而翻转方向、滑动位置，甚至震碎为更小石块填满缝隙，以求道碴更紧密契合，提供铁道更安全更强固的体质。 当「重构」（refactoring）映入眼帘，我的大脑牵动「道班工人+电动砸道机+枕木道碴」这样一幅联想画面。「重构」一词非常清楚地说明了它自身的意义和价值：在不破坏可察功能的前提下，藉由搬移、提炼、打散、凝聚┅，改善事物的体质。很多人认同这样一个信念：「非常的建设需要非常的破坏」，但是现役的应用软体、构筑过半的专案、运转中的系统，容不得推倒重来。这时候，在不破坏可察功能的前提下改善体质、强化当前的可读性、为将来的扩充性和维护性做准备、乃至於在过程中找出潜伏的「臭虫」，就成了大受欢迎的稳步前进的良方。 做为一个程式员，任谁都有看不顺眼手上程式码的经验 程式码来自你邻桌那个菜鸟，或三个月前的自己。面临此境，有人选择得过且过；然而根据我对「程式员」人格特质的了解，更多人盼望插手整顿。挽起袖子剑及履及，其勇可嘉其虑未缜。过去或许不得不暴虎凭河，忍受风险。现在，有了严谨的重构准则和严密的重构手法，「稳定中求发展」终於有了保障。 是的，把重构的概念和想法逐一落实在严谨的准则和严密的手法之中，正是这本《Refactoring》的最大贡献。重构?! 呵呵，上进的程式员每天的进行式，从来不新鲜，但要强力保证「维持程式原有的可察功能，不带进新臭虫」，重构就不能是一项靠着天份挥洒的艺术，必须是一项工程。 ■我对本书的看法 初初阅读本书，屡屡感觉书中所列的许多重构目标过於平淡，重构步骤过於琐屑。这些我们平常也都做、习惯大气挥洒的动作，何必以近乎枯燥的过程小步前进？然後，渐渐我才体会，正是这样的小步与缓步前进，不过激，不躁进，再加上完整的测试配套（是的，测试之於重构极其重要），才是「不带来破坏，不引入臭虫」的最佳保障。我个人其实不敢置信有谁能够乖乖地按步遵循实现本书所列诸多被我（从人的角度）认为平淡而琐屑的重构步骤。我个人认为，本书的最大价值，除了呼 对软体品质的追求态度，以及对重构「工程性」的认识，最终最重要的价值还在於：建立起吾人对於「目前和未来之自动化重构工具」的基本理论和实作技术上的认识与信赖。人类眼中平淡琐屑的步骤，正是自动化重构工具的基础。机器缺乏人类的「大局观」智慧，机器需要的正是切割为一个一个极小步骤的指令。一板一眼，一次一点点，这正是机器所需要的，也正是机器的专长。 本书第14章提到，Smalltalk开发环境已含自动化重构工具。我并非Smalltalk guy，我没有用过这些工具。基於技术的飞快滚动（或我个人的孤陋寡闻），或许如今你已经可以在Java, C++ 等物件导向编程环境中找到这一类自动化重构工具。 软体技术圈内，重构（refactoring）常常被拿来与设计范式（design patterns）并论。书籍市场上，《Refactoring》也与《Design Patterns》齐名。GoF曾经说『设计范式为重构提供了目标』，但本书作者Martin亦言『本书并没有提供助你完成所有知名范式的重构手法，甚至连 GoF 的23个知名范式都没有能够全部涵盖。』我们可以从这些话中理解技术的方向，以及书籍所反映的局限。我并不完全赞同Martin所言『哪怕你手上有一个糟糕的设计或甚至一团混乱，你也可以藉由重构将它加工成设计良好的程式码。』但我十分同意Martin说『你会发现所谓设计不再是一切动作的前提，而是在整个开发过程中逐渐浮现出来。』我比较担心，阅历不足的程式员在读过本书後可能发酵出「先动手再说，死活可重构」的心态，轻忽了事前优秀设计的重要性。任何技术上的说法都必须有基本假设；虽然重构（或更向上说XP，eXtreme Programming）的精神的确是「不妨先动手」，但若草率行事，代价还是很高的。重型开发和轻型开发各有所长，各有应用，世间并无万应灵药，任何东西都不能极端。过犹不及，皆不可取！ 当然，「重构工程」与「自动化重构工具」可为我们带来相当大幅度的软体品质提升，这一点我毫无异议，并且非常期待J 。 ■关於本书制作 本书在翻译与制作上保留了所有坏味道（bad smell）、重构（refactoring）、设计范式（design patterns）的英文名称，并表现以特殊字型；只在封面内页、目录、小节标题中相应地给出一个根据字面或技术意义而做的中文译名。各种「坏味道」名称尽量就其意义选用负面字眼，如泥团、夸夸、过长、过大、过多、情结、偏执、惊悚、狎昵、纯稚、冗员┅。这些其实都是助忆之用，与茶馀饭後的谈资（以及读者批评的根据J ）。 原书各小节并无序号。为便利叁考、检索或讨论时的方便，我为译本加上了序号。 本书保留相当份量的英文术语，时而英中并陈（英文为主，中文为辅）。这麽做的考量是，本书读者不可能不知道class, final, reference, public, package┅这些简短的、与Java编程息息相关的用词。另一方面，我确实认为，中文书内保留经过挑选的某些英文术语，有利於整体阅读效果。 两个需要特别说明的用词是Java编程界惯用的 "field" 和 "method"。它们相当於C++ 的 "data member" 和 "member function"。由於出现次数实在频繁，为降低中英夹杂程度，我把它们分别译为「栏位」和「函式」 如果将 "method" 译为「方法」，恐怕术语突出性不高。此外，本书将「创造建立新物件」的 "create" 动作译为「创建」。「static栏位与instance栏位」、「reference物件与value物件」等等则保留部分英文，并选用如上的特殊字型。凡此总总，相信一进入书中您很快可以感受本书术语风格。 本书还有诸多地方采中英并陈（中文为主，英文为辅）方式，意在告诉读者，我们（译者）深知自己的不足与局限，惟恐造成您对中译名词的误解或不习惯，所以附上原文。 中文版（本书）已将英文版截至2003/06/18为止之勘误，修正於纸本。 ■一点点感想 Martin Fowler表现於原书的写作风格是：简洁，爱用代名词和略称。这使得读者往往需要在字面上揣度推敲。我期盼（并相信）经过技术意义的反刍、中英术语的并陈、中文表述的努力，中文版（本书）在阅读时间和理解时间和记忆深度上，较之英文版，能够为以华文为母语的读者提高10倍以上的成效。 本书由我和熊节先生合译。熊节负责第一个pass，我负责後继工作。中文版（本书）为读者带来的阅读和理解上的效益，熊节居於首功 虽说做的是第一个pass，我从初稿品质便可看出他多次反覆推敲和文字琢磨的刻痕。至於整体风格、中英术语的选定、版面的呈现、乃至於全盘技术内涵的表现，如果有任何差错，责任都是我的J 。 做为一个资讯技术教育者，以及一个资讯技术传播者，我在超过10年的写译历程中，观察了不同级别的技术书品在读书市场上的兴衰起伏。这些适可反映大环境下技术从业人员及学子们的某些面向和取向。我很高兴看到我们的中文技术书籍（着译皆含）从早期盈盈满满的初阶语言用书，逐渐进化到中高阶语言用书、作业系统、技术内核、程式库/框架、再至设计/分析、软体工程。我很高兴看到这样的变化。我很高兴看到《Design Patterns》、《Refactoring》、《Agile┅》、《UML┅》、《XP┅》之类的书在中文书籍市场中现身，并期盼它们有丰富的读者。 中文版（本书）支援网站有一个「术语 英中繁简」对照表。如果您有需要，欢迎访问，网址如下，并欢迎给我任何意见。谢谢。 侯捷 2003/06/18 于台湾.新竹 jjhou@jjhou.com（电子邮箱） http://www.jjhou.com（繁体）（术语对照表http://www.jjhou.com/terms.htm） http://jjhou.csdn.net（简体）（术语对照表http:// jjhou.csdn.net/terms.htm）

Martin Fowler是一位独立咨询顾问，他运用对象技术解决企业问题已经超过十年。他的顾问领域包括健康管理、金融贸易，以及法人财务。他的客户包括Chrysler，Citibank，UK National Health Service，AndersenConsulting，NetscapeCommunications。此外Fowler也是objects、UML、patterns技术的一位合格讲师，他是《AnalysisPatterns》和《UMLDistilled》的作者。

从前，有位咨询顾问参访一个开发项目。系统核心是个class hierarchy（类阶层体系），顾问看了开发人员所写的一些代码。他发现整个体系相当凌乱，上层classes对自己的运作方式做了一些假设，这些假设被嵌入并被继承下去。但是这些假设并不适合所有 subclasses，导致覆写（overridden）行为非常繁重。只要在superclass内做点修改，就可以减少许多覆写必要。在另一些地方，superclass的某些意图并未被良好理解，因此其中某些行为在subclasses内重复出现。还有一些地方，好几个subclasses做相同的事情，其实可以把它们搬到class hierarchy的上层去做。 这位顾问于是建议项目经理看看这些代码，把它们整理一下，但是经理并不热衷于此，毕竟程序看上去还可以运行，而且项目面临很大的进度压力。于是经理说，晚些时候再抽时间做这些整理工作。 顾问也把他的想法告诉了在这个class hierarchy上工作的程序员，告诉他们可能发生的事情。程序员都很敏锐，马上就看出问题的严重性。他们知道这并不全是他们的错，有时候的确需要借助外力才能发现问题。程序员立刻用了一两天的时间整理好这个class hierarchy，并删掉了其中一半代码，功能毫发无损。他们对此十分满意，而且发现系统速度变得更快，更容易加入新classes或使用其它classes。 项目经理并不高兴。进度排得很紧，许多工作要做。系统必须在几个月之后发布，许多功能还等着加进去，这些程序员却白白耗费两天时间，什么活儿都没干。原先的代码运行起来还算正常，他们的新设计显然有点过于「理论」且过于「无瑕」。项目要出货给客户的，是可以有效运行的代码，不是用以取悦学究们的完美东西。顾问接下来又建议应该在系统的其它核心部份进行这样的整理工作，这会使整个项目停顿一至二个星期。所有这些工作只是为了让代码看起来更漂亮，并不能给系统添加任何新功能。 你对这个故事有什么看法﹖你认为这个顾问的建议（更进一步整理程序）是对的吗？你会因循那句古老的工程谚语吗：「如果它还可以运行，就不要动它」。 我必须承认我自己有某些偏见，因为我就是那个顾问。六个月之后这个项目宣告失败，很大的原因是代码太复杂，无法除错，也无法获得可被接受的性能。 后来，项目重新激活，几乎从头开始编写整个系统，Kent Beck被请去做了顾问。他做了几件迥异以往的事，其中最重要的一件就是坚持以持续不断的重构行为来整理代码。这个项目的成功，以及重构（refactoring）在这个成功项目中扮演的角色，鼓舞了我写这本书的动机，如此一来我就能够把Kent和其它一些人已经学会的「以重构方式改进软件质量」的知识，传播给所有读者。 什么是重构（Refactoring）? 所谓重构是这样一个过程：「在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构」。重构是一种有纪律的、经过训练的、有条不紊的程序整理方法，可以将整理过程中不小心引入错误的机率降到最低。本质上说，重构就是「在代码写好之后改进它的设计」。 「在代码写好之后改进它的设计」？这种说法有点奇怪。按照目前对软件开发的理解，我们相信应该先设计而后编码（coding）。首先得有一个良好的设计，然后才能开始编码。但是，随着时间流逝，人们不断修改代码，于是根据原先设计所得的系统，整体结构逐渐衰弱。代码质量慢慢沉沦，编码工作从严谨的工程堕落为胡砍乱劈的随性行为。 「重构」正好与此相反。哪怕你手上有一个糟糕的设计，甚至是一堆混乱的代码，你也可以藉由重构将它加工成设计良好的代码。重构的每个步骤都很简单，甚至简单过了头，你只需要把某个值域（field）从一个class移到另一个class，把某些代码从一个函数（method）拉出来构成另一个函数，或是在class hierarchy中把某些代码推上推下就行了。但是，聚沙成塔，这些小小的修改累积起来就可以根本改善设计质量。这和一般常见的「软件会慢慢腐烂」的观点恰恰相反。 通过重构（refactoring），你可以找出改变的平衡点。你会发现所谓设计不再是一切动作的前提，而是在整个开发过程中逐渐浮现出来。在系统构筑过程中，你可以学习如何强化设计；其间带来的互动可以让一个程序在开发过程中持续保有良好的设计。 本书有些什么﹖ 本书是一本重构指南（guide to refactoring），为专业程序员而写。我的目的是告诉你如何以一种可控制且高效率的方式进行重构。你将学会这样的重构方式：不引入「臭虫」（错误），并且有条不紊地改进程序结构。 按照传统，书籍应该以一个简介开头。尽管我也同意这个原则，但是我发现以概括性的讨论或定义来介绍重构，实在不是件容易的事。所以我决定拿一个实例做为开路先锋。第1章展示一个小程序，其中有些常见的设计缺陷，我把它重构为更合格的面向对象程序。其间我们可以看到重构的过程，以及数个很有用的重构准则。如果你想知道重构到底是怎么回事，这一章不可不读。 第2章涵盖重构的一般性原则、定义、以及进行原因，我也大致介绍了重构所存在的一些问题。第3章由Kent Beck介绍如何嗅出代码中的「坏味道」，以及如何运用重构清除这些坏味道。「测试」在重构中扮演非常重要的角色，第4章介绍如何运用一个简单的（源码开放的）Java测试框架，在代码中构筑测试环境。 本书的核心部份，重构名录（catalog of refactorings），从第5章延伸至第12章。这不是一份全面性的名录，只是一个起步，其中包括迄今为止我在工作中整理下来的所有重构准则。每当我想做点什么 ─ 例如Replace Conditional with Polymorphism ─ 的时候，这份名录就会提醒我如何一步一步安全前进。我希望这是值得你日后一再回顾的部份。 本书介绍了其它人的许多研究成果，最后数章就是由他们之中的几位所客串写就。Bill Opdyke在第13章记述他将重构技术应用于商业开发过程中遇到的一些问题。Don Roberts和John Brant在第14章展望重构技术的未来 ─ 自动化工具。我把最后一章（第15章）留给重构技术的顶尖大师，Kent Beck。 在Java中运用重构 本书全部以Java撰写实例。重构当然也可以在其它语言中实现，而且我也希望这本书能够对其他语言使用者带来帮助。但我觉得我最好在本书中只使用Java，因为那是我最熟悉的语言。我会不时写下一些提示，告诉读者如何在其它语言中进行重构，不过我真心希望看到其它人在本书基础上针对其它语言写出更多重构方面的书籍。 为了最大程度地帮助读者理解我的想法，我不想使用Java语言中特别复杂的部份。所以我避免使用inner class（内嵌类）、reflection（反射机制）、thread（线程）以及很多强大的Java特性。这是因为我希望尽可能清楚展现重构的核心。 我应该提醒你，这些重构准则并不针对并发（concurrent）或分布式（distributed）编程。那些主题会引出更多重要的事，超越了本书的关心范围。 谁该阅读本书﹖ 本书瞄准专业程序员，也就是那些以编写软件为生的人。书中的示例和讨论，涉及大量需要详细阅读和理解的代码。这些例子都以Java完成。之所以选择Java，因为它是一种应用范围愈来愈广的语言，而且任何具备C语言背景的人都可以轻易理解它。Java是一种面向对象语言，而面向对象机制对于重构有很大帮助。 尽管关注对象是代码，重构（refactoring）对于系统设计也有巨大影响。资深设计师（senior designers）和架构规划师（architects）也很有必要了解重构原理，并在自己的项目中运用重构技术。最好是由老资格、经验丰富的开发人员来引入重构技术，因为这样的人最能够良好理解重构背后的原理，并加以调整，使之适用于特定工作领域。如果你使用Java以外的语言，这一点尤其必要，因为你必须把我给出的范例以其它语言改写。 下面我要告诉你：如何能够在不遍读全书的情况下得到最多知识。 如果你想知道重构是什么，请阅读第1章，其中示例会让你清楚重构过程。 如果你想知道为什么应该重构，请阅读前两章。它们告诉你「重构是什么」以及「为什么应该重构」。 如果你想知道该在什么地方重构，请阅读第3章。它会告诉你一些代码特征，这些特征指出「这里需要重构」。 如果你想真正（实际）进行重构，请完整阅读前四章，然后选择性地阅读重构名录（refactoring catalog）。一开始只需概略浏览名录，看看其中有些什么，不必理解所有细节。一旦真正需要实施某个准则，再详细阅读它，让它来帮助你。名录是一种具备查询价值的章节，你也许并不想一次把它全部读完。此外你还应该读一读名录之后的「客串章节」，特别是第15章。