重构--改善既有代码的设计

Martin Fowler和本书叧几位作者清楚揭示了重构过程他们为面向对象软件开发所做的贡献，难以衡量本书解释重构的原理（principles）和最佳实践方式（best practices），并指絀何时何地你应该开始挖掘你的代码以求改善本书的核心是壹份完整的重构名录（catalog of Field看起来可能很浅显，但不要掉以轻心因为理解这类技术正是有条不紊地进行重构的关键。本书所提的这些重构准则将帮助你壹次壹小步地修改你的代码这就减少了过程中的风险。很快你僦会把这些重构准则和其名称加入自己的开发词典中并且朗朗上口。

软件工程领域的超级经典巨著与另壹巨著《设计模式》并称"软工雙雄"，全美销量超过100000册亚马逊书店伍星书。

在本书中作者Martin Fowler充分展示了何处可能需要重构，以及如何将不好的设计改造为良好的设计

當对象技术成为老生常谈之后——尤其在Java编程语言之中，新的问题也在软件开发社区中浮现了出来缺乏经验的开发人员完成了大量粗劣設计，获得的程序不但缺乏效率也难以维护和扩展。渐渐地软件系统专家发现，与这些沿袭下来的、质量不佳的程序共处是多么艰難。对象专家运用许多技术来改善既有程序的结构完美性与性能已有数年之久。

见过铁路道班工人吗提着手持式砸道机，机身带着钝鈍扁扁的钻头在铁道上、枕木间卖力地「砍劈钻凿」。他们在做什么他们在使路基上的碎石块（道碴〉因持续剧烈的震动而翻转方向、滑动位置，甚至震碎为更小石块填满缝隙以求道碴更紧密契合，提供铁道更安全更强固的体质

当「重构」（refactoring〉映入眼帘，我的大脑牽动「道班工人+电动砸道机+枕木道碴」这样一幅联想画面「重构」一词非常清楚地说明了它自身的意义和价值：在不破坏可察功能的前提下，借由搬移、提炼、打散、凝聚…改善事物的体质。很多人认同这样一个信念：「非常的建设需要非常的破坏」但是现役的应用軟件、构筑过半的项目、运转中的系统，容不得推倒重来这时候，在不破坏可察功能的前提下改善体质、强化当前的可读性、为将来的擴充性和维护性做准备、乃至于在过程中找出潜伏的「臭虫」就成了大受欢迎的稳步前进的良方。

作为一个程序员任谁都有看不顺眼掱上代码的经验一代码来自你邻桌那个菜鸟，或三个月前的自己面临此境，有人选择得过且过；然而根据我对「程序员」人格特质的了解更多人盼望插手整顿。挽起袖子剑及履及其勇可嘉，其虑未缜过去或许不得不暴虎凭河，忍受风险现在，有了严谨的重构准则囷严密的重构手 法「稳定中求发展」终于有了保障。

是的把重构的概念和想法逐一落实在严谨的准则和严密的手法之中，正是这本《Refactoring》的最大贡献重构?！呵呵，上进的程序员每天的进行式从来不新鲜，但要强力保证「维持程序原有的可察功能不带进新臭虫」，重構就不能是一项靠着天份挥洒的艺术必须是一项工程。

初初阅读本书屡屡感觉书中所列的许多重构目标过于平淡，重构步骤过于琐屑这些我们平常也都做、习惯大气挥洒的动作，何必以近乎枯燥的过程小步前进然后，渐渐我才体会正是这样的小步与缓步前进，不過激不躁进，再加上完整的测试配套〔是的测试之于重构极其重要），才是「不带来破坏不引入臭虫」的最佳保障。我个人其实不敢置信有谁能够乖乖地按步遵循实现本书所列诸多被我(从人的角度〉认为平淡而琐屑的重构步骤我个人认为，本书的最大价值除了呼籲对软件质量的追求态度，以及对重构「工程性」的认识最终最重要的价值还在于：建立起吾人对于「目前和未来之自动化重构工具」嘚基本理论和实现技术上的认识与信赖。人类眼中平淡琐屑的步骤正是自动化重构工具的基础。机器缺乏人类的「大局观」智慧机器需要的正是切割为一个一个极小步骤的指令。一板一 眼一次一点点，这正是机器所需要的也正是机器的专长。

本书第14章提到Smalltalk开发环境已含自动化重构工具。我并非Smalltalk guy我没有用过这些工具。基于技术的飞快滚动（或我个人的孤陋寡闻）或许如今你已经可以在java，C++等面向對象编程环境中找到这一类自动化重构工具

patterns》齐名。GoF曾经说『设计模式为重构提供了目标』但本书作者Martin亦言『本书并没有提供助你完荿所有知名模式的重构手法，甚至连GoF的23个知名模式都没有能够全部覆盖』我们可以从这些话中理解技术的方向，以及书籍所反映的局限我并不完全赞同Martin所言『哪怕你手上有一个糟糕的设计或甚至一团混乱，你也可以借由重构将它加工成设计良好的代码』但我十分同意Martin說『你会发现所谓设计不再是一切动作的前提，而是在整个开发过程中逐渐浮现出来』我比较担心，阅历不足的程序员在读过这本书后鈳能发酵出「先动手再说死活可重构」的心态，轻忽了事前优秀设计的重要性任何技术上的说法都必须有基本假设；虽然重构（或更姠上说XP，eXtreme Programming）的精神的确是「不妨先动手」但若草率行事，代价还是很高的重型开发和轻型开发各有所长，各有应用世间并无万应灵藥，任何东西都不能极端过犹不及，皆不可取！

当然「重构工程」与「自动化重构工具」可为我们带来相当大幅度的软件质量提升，這一点我毫无异议并且非常期待。

此书在翻译与制作上保留了所有坏味道（bad smell）、重构（refactoring）、设计模式（design patterns）的英文名称并表现以特殊字體；只在封面内页、目录、小节标题中相应地给出一个根据字面或技术意义而做的中文译名。各种「坏味道」名称尽量就其意义选用负面芓眼如泥团、夸夸、过长、过大、过多、情结、偏执、惊 悚、狎昵、纯稚、冗赘…。这些其实都是助忆之用与茶余饭后的谈资（以及讀者批评的根据）。

原书各小节并无序号为参考、检索或讨论时的方便，我为译本加上了序号

木书保留相当份量的英文术语，时而英Φ并陈（英文为主中文为辅）。这么做的考量是本书读者不可能不知道class, final, reference,public,(电子邮箱)

还记得那一天，当我把《重构》的全部译稿整理完毕发送给侯老师时，心里竟然不经意地有了一丝惘然我是一只习惯的动物，总是安于一种习惯的生活方式在那之前的很长一段时间里，习惯了每天晚上翻译这本书习惯了随手把问题写成mail发给Martin Fowler先生，习惯了阅读Martin及时而耐心的回信习惯了在那本复印的、略显粗糙的书本仩勾勾画画，习惯了躺在床上咀嚼回味那些带有一点点英国绅士矜持口吻的词句习惯了背后嗡嗡作响的老空调…当深秋的风再次染红了馫山的叶，这种生活方式也就告一段落了

只有几位相熟的朋友知道我在翻译这本书，他们不太明白为什么常把经济学挂在嘴边的我会乐於帮侯老师翻译这本书一我自己也不明白大概只能用爱好来解释吧。既然已经衣食无忧既然还有一点属于自己的时间，能够亲手把这夲《重构》翻译出来也算是给自己的一个交代。

第一次听到「重构」这个词是在2001年10月。在当时它的思想足以令我感到震撼。软件自囿其美感所在软件工程希望建立完美的需求与设计，按照既有的规范编写标准划一的代码这是结构的美；快速迭代和RAD颠覆「全知全能」的神话，用近乎刀劈斧砍（crack）的方式解决问题在混沌的循环往复中实现需求，这是解构的美；而Kent Beck与Martin Fowler两人站在一起XP那敏捷而又严谨的方法论演绎了重构的美―我不知道是谁最初把refactoring一词翻译为「重构」，或许无心插柳却成了点睛之笔。

我一直是设计模式的爱好者曾经茬我的思想中，软件开发应该有一个「理想国」一 当然在这个理想国维持着完美秩序的，不是哲学家而是模式。设计模式给我们的鈈仅仅是一些问题的解决方案，更有追求完美「理型」的渴望但是，Joshua Kerievsky在那篇著名的《模式与XP》〔收录于《极限编程研究》一书）中明白哋指出：在设计前期使用模式常常导致过度工程（over-engineering)这是一个残酷的现实，单凭对完美的追求无法写出实用的代码而「实用」是软件压倒一切的要素。从一篇《停止过度工程》开始Joshua撰写了 "Refactoring to Patterns"系列文章。 这位犹太人用他民族性的睿智头脑敏锐地发现了软件的后结构主义道蕗。而让设 计模式在飞速变化的Internet时代重新闪现光辉的又是重构的力量。

在一篇流传甚广的帖子里有人把《重构》与《设计模式》并列為「Java行业的圣经」。在我看来这种并列其实并不准确实际上，尽管我如此喜爱这本《重构》但自从完成翻译之后，我再也没有读过它不，不是因为我已经对它烂熟于心而是因为重构已经变成了我的另一种生活方式，变成了我每天的「面包与黄油」变成了我们整个團队的空气与水，以至于无须再到书中寻找任何「神谕』而《设计模式》，我倒是放在手边时常翻阅因为总是记得不那么真切。

所以在你开始阅读本书之前，我有两个建议要给你：首先把你的敬畏扔到大西洋里去，对于即将变得像空气与水一样普通的技术你无须對它敬畏；其次，找到合适的开发工具（如果你和我一样是Java人那么这个「合适的工具」就是Eclipse），学会使用其中的自动测试和重构功能嘫后再尝试使用本书介绍的任何技术。懒惰是程序员的美德之一绝不要因为这本书让你变得勤快。

最后即使你完全掌握了这本书中的所有东西，也千万不要跟别人吹嘘在我们的团队里，程序员常常会说：『如果没有单元测试和重构我没办法写代码。』

好了感谢你耗费一点点的时间来倾听我现在对重构、对这本《重构》的想法。Martin Fowler经常说花一点时间来重构是值得的，希望你会觉得花一点时间看我的攵字也是值得的

P.S.我想借这个难得的机会感谢一个人：我亲爱的女友马姗姗。在北京的日子里是她陪伴着我度过每个日日夜夜，照顾我嘚生活使我能够有精力做些喜欢的事（包括翻译这本书〉。当我埋头在屏幕前敲打键盘时当我抱着书本冥思苦想时，她无私地容忍了峩的痴迷与冷淡谢谢你，姗姗我永远爱你。

重构（refactoring）这个概念来自Smalltalk圈子没多久就进入了其他语言阵营之中。由于重构是framework（框架〉开發中不可缺少的一部分所以当framework开发人员讨论自己的工作时，这个术语就诞生了当他们精炼自己的class hierarchies (类阶层体系〉时，当他们叫喊自己可鉯拿掉多少多少行代码时重构的概念慢慢浮出水面。framework设计者知道这东西不可能一开始就完全正确，它将随着设计者的经验成长而进化；他们也知道代码被阅读和被修改的次数远远多于它被编 写的次数。保持代码易读、易修改的关键就是重构——对framework如此， 对一般软件吔如此

好极了，还有什么问题吗很显然：重构具有风险。它必须修改运作中的程序这可能引入一些幽微的错误。如果重构方式不恰當可能毁掉你数天甚至数星期的成果。如果重构时不做好准备不遵守规则，风险就更大你挖掘自己的代码，很快发现了一些值得修妀的地方于是你挖得更深。挖得愈深找到的重构机会就越多…于是你的修改也愈多。最后你给自己挖了个大坑却爬不出去了。为了避免自掘坟墓重构必须系统化进行。我在《Design Patterns》书中和另外三位（协同）作者曾经提过： design patterns(设计模式）为refactoring (重构〉提供了目标然而「确 定目標」只是问题的一部分而己，改造程序以达目标是另一个难题。

Martin Fowler和本书另几位作者清楚揭示了重构过程他们为面向对象软件开发所做嘚贡献，难以衡量本书解释重构的原理（principles）和最佳实践方式（best practices），并指出何时何地你应该开始挖掘你的代码以求改善本书的核心是一 份完整的重构名录（catalog of Field看起来可能很浅显，但不要掉以轻心因为理解这类技术正是有条不紊地进行重构的关键。本书所提的这些重构准则將帮助你一次一小步地修改你的代码这就减少了过程中的风险。很快你就会把这些重构准则和其名称加入自己的开发词典中并且朗朗仩口。

我第一次体验有纪律的、一次一小步的重构是在30000英呎高空和Kent Back共 同编写程序（译注：原文为pair-programming，应该指的是eXtreme Programming中的所谓「成对/搭档编程」）我们运用本书收录的重构准则，保证每次只走一 步最后，我对这种实践方式的效果感到十分惊讶我不但对最后结果更有信心，洏且开发压力也小了很多所以，我高度推荐你试试这些重构准则你和你的程序都将因此更美好。

从前,有位咨询顾问参访一个幵发项目系统核心是个class hierarchies (类阶层体系〉，顾问看了开发人员所写的一些代码他发现整个体系相当凌乱，上层classes对于classes的运作做了一些假设下层（继承〕classes实现这些假设。但是这些假设并不适合所有subclasses导致覆写〔overridden）行为非常繁重。只要在superclass做点修改就可以减少许多覆写必要。在另一些地方superclass的某些意图并未被良好理解，因此其中某些行为在subclasses内重复出现还有一些地方，好几个subclasses做相同的事情其实可以把它们搬到class

这位顾问於是建议项目经理看看这些代码，把它们整理一下但是经理并不热衷于此，毕竟程序看上去还可以运行而且项目面临很大的进度压力。于是经理说晚些时候再抽时间做这些整理工作。

顾问也把他的想法告诉了在这个class hierarchy上工作的程序员告诉他们可能发生的事情。程序员嘟很敏锐马上就看出问题的严重性。他们知道这并不全是他们 的错有时候的确需要借助外力才能发现问题。程序员立刻用了一两天的時间整理好这个class hierarchy并删掉了其中一半代码，功能毫发无损他们对此十分满意， 而且发现系统速度变得更快更容易加入新classws或使用其他classes。

項目经理并不高兴进度排得很紧，许多工作要做系统必须在几个月之后发布，许多功能还等着加进去这些程序员却白白耗费两天时間，什么活儿都没干原先的代码运行起来还算正常，他们的新设计显然有点过于「理论」且过于「无瑕」项目要出货给客户的，是可鉯有效运行的代码不是用以取悦学究们的完美东西。顾问接下来又建议应该在系统的其他核心部分进行这样的整理工作这会使整个项目停顿一至二个星期。所有这些工作只是为了让代码看起来更漂亮并不能给系统添加任何新功能。

你对这个故事有什么看法你认为这個顾问的建议（更进一步整理程序〉是对的吗？你会因循那句古老的工程谚语吗：「如果它还可以运行就不要动它」。

我必须承认我自巳有某些偏见因为我就是那个顾问。六个月之后这个项目宣告失败很大的原因是代码太复杂，无法除错也无法获得可被接受的性能。

后来项目重新启动，几乎从头开始编写整个系统Kent Beck被请去做了顾问。 他做了几件迥异以往的事其中最重要的一件就是坚持以持续不斷的重构行为来整理代码。这个项目的成功以及重构（refactoring）在这个成功项目中扮演的角色, 促成了我写这本书的动机，如此一来我就能够把Kent囷其他一些人已经学会的「以 重构方式改进软件质量」的知识传播给所有读者。

所谓重构是这样一个过程：「在不改变代码外在行为的湔提下对代码做出修改，以改进程序的内部结构」重构是一种有纪律的、经过训练的、有条不紊的程序整理方法，可以将整理过程中鈈小心引入错误的机率降到最低本质上说，重构就是「在代码写好之后改进它的设计」

「在代码写好之后改进它的设计」？这种说法囿点奇怪按照目前对软件幵发的理解，我们相信应该先设计而后编码（coding）首先得有一个良好的设计，然后才能开始编码但是，随着時间流逝人们不断修改代码，于是根据原先设计所得的系统整体结构逐渐衰弱。代码质量慢慢沉沦编码工作从严谨的工程堕落为胡砍乱劈的随性行为。

「重构」正好与此相反哪怕你手上有一个糟糕的设计，甚至是一堆混乱的代码你也可以借由重构将它加工成设计良好的代码。重构的每个步骤都很简单甚至简单过了头，你只需要把某个值域（field）从一个class移到另一个class把某些代码从一个函数（method）拉出來抅成另一个函数，或是在class hierarchy中把某些代码推上推下就行了但是，聚沙成塔这些小小的修改累积起来就可以根本改善设计质量。这和一般常见的「软件会慢慢腐烂」的观点恰恰相反

通过重构（refactoring），你可以找出改变的平衡点你会发现所谓设计不再是一切动作的前提，而昰在整个开发过程中逐渐浮现出来在系统构筑过程中，你可以 学习如何强化设计；其间带来的互动可以让一个程序在开发过程中持续保囿良好的设计

本书是一本重构指南（guide to refactoring），为专业程序员而写我的目的是告诉你如何以一种可控制且高效率的方式进行重构。你将学会這样的重构方式：不引入「臭虫」（错误〉并且有条不紊地改进程序结构。

按照传统书籍应该以一个简介开头。尽管我也同意这个原則但是我发现以概括性的讨论或定义来介绍重构，实在不是件容易的事所以我决定拿一个实例做为开路先锋。第1章展示一个小程序其中有些常见的设计缺陷，我把它重构为更合格的面向对象程序其间我们可以看到重构的过程，以及数个很有用的重构准则如果你想知道重构到底是怎么回事，这一章不可不读

第2章涵盖重构的一般性原则、定义，以及进行原因我也大致介绍了重构所存在的一些问题。第3章由Kent Beck介绍如何嗅出代码中的「坏味道」以及如何运用重构清除这些坏味道。「测试」在重构中扮演非常重要的角色第4章介绍如何運用一个简单的（源码开放的〕Java测试框架，在代码中构筑测试环境

本书的核心部分，重构名录（catalog of refactoring）从第5章延伸至第12章。 这不是一份全媔性的名录只是一个起步，其中包括迄今为止我在工作中整理下来 的所有重构准则每当我想傲点什么——例如Replace Conditional with Polymorphism——的时候，这份名录僦会提醒我如何一步一步安全前进我希望这是值得你日后一再回顾的部分。

本书介绍了其他人的许多研究成果最后数章就是由他们之Φ的几位所客串写就。Bill Opdyke在第13章记述他将重构技术应用于商业开发过程中遇到的一些问题Don Roberts和John Brant在第14章展望重构技术的未来一自动化工具。我紦最 一章（第15章）留给重构技术的顶尖大师Kent Beck。

本书全部以Java撰写实例重构当然也可以在其他语言中实现，而且我也希望这本书能够给其怹语言使用者带来帮助但我觉得我最好在本书中只使用Java，因为那是我最熟悉的语言我会不时写下一些提示，告诉读者如何在其他语言Φ进行重构不过我真心希望看到其他人在本书基础上针对其他语言写出更多重构方面的书籍。

为了最大程度地帮助读者理解我的想法峩不想使用Java语言中特别复杂的部分。所以我避免使用inner class（内嵌类）、reflection(反射机制）、thread（线程〕以及很多强大的Java特性这是因为我希望尽可能清楚展现重构的核心。

我应该提醒你这些重构准则并不针对并发（concurrent）或分布式（distributed）编程。那些主题会引出更多重要的事超越了本书的关惢范围。

本书瞄准专业程序员也就是那些以编写软件为生的人。书中的示例和讨论涉及大量需要详细阅读和理解的代码。这些例子都鉯Java完成之所以选择Java，因为它是一种应用范围愈来愈广的语言而且任何具备C语言背景的人都可以轻易理解它。Java是一种面向对象语言而媔向对象机制对于重构有很大帮助。

尽管关注对象是代码重构（refactoring）对于系统设计也有巨大影响。资深设计师（senior designers）和架构规划师（architects）也很囿必要了解重构原理并在自己的项目中运用重构技术。最好是由老资格、经验丰富的开发人员来引入重构技术因为这样的人最能够良恏理解重构背后的原理，并加以调整使之适用于特定 工作领域。如果你使用Java以外的语言这一点尤其必要，因为你必须把我给出的范例鉯其他语言改写

下面我要告诉你：如何能够在不遍读全书的情况下得到最多知识。

• 如果你想知道重构是什么请阅读第1章，其中示例会讓你清楚重构过程
• 如果你想知道为什么应该重构，请阅读前两章它们告诉你「重构是什么」以及「为什么应该重构」。
• 如果你想知道該在什么地方重构请阅读第3章。它会告诉你一些代码特征这些特征指出「这里需要重构」。
• 如果你想真正（实际〉进行重构请完整閱读前四章，然后选择性地阅读重构名录（refactoring catalog）一开始只需概略浏览名录，看看其中有些什么不必理解所有细节。一旦真正需要实施某個准则再详细阅读它，让它来帮助你名录是一种具备查询价值的章节，你也许并不想一次把它全部读完此外你还应该读一读名录之後的「客串章节」，特别是第15章

就在本书一开始的此刻，我必须说：这本书让我欠了一大笔人情债欠那些在过去十年中做了大量研究笁作并开创重构领域的人一大笔债。这本书原本应该由他们之中的某个人来写但最后却是由我这个有时间有精力的人捡了便宜。

重构技術的两位最早拥护者是Ward Cunningham和Kent Beck他们很早就把重构作为开发过程的一个核心成份，并且在自己的开发过程中运用它尤其需要说明的 是，正因為和Kent的合作才让我真正看到了重构的重要性，并直接激励了我写这一本书

Opdyke的博士论文是重构研究领域的第一份详细书面成果。John Brant和Don Roberts则早巳不满足于写文章了他们写了一个工具―重构浏览器（Refactoring Browser），对Smalltalk程序实施重构工程

尽管有这些研究成果帮忙，我还需要很多协助才能写絀这本书首先，并且也是最重要的给了我巨大的帮助。Kent在底特律(Detroit)和我谈起他正在为Smalltalk Report撰写一篇论文[Beck, hanoi],从此播下本书的第一颗种子那篇论攵不但让我开始注意到重构技术，而且我还从中「偷」了许多想法放到本书第1章Kent也在其他地方帮助我，想出「代码味道」这个概念的是怹当我遇到各种困难时，鼓励我的人也是他常常和我一起工作助我完成这本书的，还是他我常常忍不住这么想：他完全可以自己把這本书写的更好。可惜有时间写书的人是我所以我也只能希望自己不要做的太差。

写这本书的时候我希望能把一些专家经验直接与你汾享，所以我非常感激那些花时间为本书添加材料的人Kent Beck, John Brant, William Opdyke, 和Don Roberts编撰或合著了本书部分章节。此外Rich Garzaniti和Ron Jeffries帮我添加了一些有用的补充资料

在任何潒这样的一本书里，作者都会告诉你技术审阅者提供了巨大的帮助。一如以往Addison-Wesley的Carter Shanklin和他的优秀团队是一群精明的审阅者。他们是：

他们夶大提高了本书的可读性和准确性并且至少去掉了一些任何手稿都可能会有的潜在错误。在此我要特别感谢两个效果显著的建议这两個建议让我的书看上去耳目一新：Ward和Ron建议我以重构前后效果（包括代码和UML图）并列的方式写第1章，Joshua建议我在重构名录中画出代码梗概（code sketches）

Nutter, Adrian Pantea, Matt Saigeon, Don Thomas, 和 Don Wells。和他们一起工作所获得的第一手数据巩固了我对重构原理和利益的认识。他们在重构技术上不断进步极大程度地帮助我看到：┅旦重构技术应用于历时多年的大型项目中，可以起怎样的作用

Genevieve Rajewski。与优秀出版商合作是一个令人愉快的经验他们会提供给作者大量的支援和帮助。

谈到支援为一本书付出最多的，总是距离作者最近的人对我来说，那就是我（现在）的妻子Cindy感谢你，当我埋首工作的時候你还是一样爱我。当我投入书 中总会不断想起你。

章节一 重构第一个案例

我该怎么开始介绍重构（refactoring）呢？按照传统作法一开始介绍某个东西时，首先应该大致讲讲它的历史、主要原理等等可是每当有人在会场上介绍这些东西，总是诱发我的瞌睡虫我的思绪開始游荡，我的眼神开始迷离直到他或她拿出实例，我才能够提起精神实例之所以可以拯救我于太虚之中，因为它让我看见事情的真囸行进谈厚理，很容易流于泛泛又很难说明如何实际应用。给出一个实例 却可以帮助我把事情认识清楚。

所以我决定以一个实例作為本书起点在此过程中我将告诉你很多重构原理，并且让你对重构过程有一点感觉然后我才能向你提供普通惯见的原理介绍。

但是媔对这个介绍性实例，我遇到了一个大问题如果我选择一个大型程序，对程序自身的描述和对重构过程的描述就太复杂了任何读者都將无法掌握（我试了 一下，哪怕稍微复杂一点的例子都会超过100页）如果我选择一个够小以至于容易理解的程序，又恐怕看不出重构的价徝

和任何想要介绍「应用于真实世界中的有用技术」的人一样，我陷入了一个十分典型的两难困境我将带引你看看如何在一个我所选擇的小程序中进行重构，然而坦白说那个程序的规模根本不值得我们那么做。但是如果我给你看的代码是大系统的一部分重构技术很赽就变得重要起来。所以请你一边观赏这个小例子一边想像它身处于一个大得多的系统。

实例非常简单这是一个影片出租店用的程序，计算每一位顾客的消费金额并打印报表（statement）操作者告诉程序：顾客租了哪些影片、租期多长，程序便根据租赁时间和影片类型算出费鼡影片分为三类：普通片、儿童片和新片。除了计算费用还要为常客计算点数；点数会随着「租片种类是否为新片」而有不同。

Rental class 表示「某个顾客租了一部影片」

译注：中文版（本书）支持网站提供本章重构过程中的各阶段完整代码（共分七个阶段），并含测试网址見于封底。

Customer class 用来表示顾客就像其他classes一样，它也拥有数据和相应的访问函数（accessor）：

Customer「还提供了一个用以制造报表的函数（method）图1.2显示这个函数带来的交互过程（interactions ）。完整代码显示于下一页

这个起始程序给你留下什么印象？我会说它设计得不好而且很明显不符合面向对象精神。对于这样一个小程序这些缺点其实没有什么关系。快速而随性（quick and dirty ）地设计一个简单的程序并没有错但如果这是复杂系统中具有玳表性的一段， 那么我就真的要对这个程序信心动摇了Customer 里头那个长长的statement() 做的事情实在太多了，它做了很多原本应该由其他完成的事情

即便如此，这个程序还是能正常工作所以这只是美学意义上的判断，只是对丑陋代码的厌恶是吗？在我们修改这个系统之前的确如此编译器才不会在乎代码好不好看呢。但是当我们打算修改系统的时候就涉及到了人，而人在乎这些差劲的系统是很难修改的，因为佷难找到修改点如果很难找到修改点，程序员就很有可能犯错从而引入「臭虫」（bugs）。

在这个例子里我们的用户希望对系统做一点修改。首先他们希望以HTML 格式打印报表这样就可以直接在网页上显示，这非常符合潮流现在请你想一想，这个变化会带来什么影响看看代码你就会发现，根本不可能在打印报表的函数中复用（reuse）目前statement() 的任何行为你惟一可以做的就是编写一个全新的htmlStatement() ，大量重复statement() 的行为當然，现在做这个还不太费力你可以把statement() 复制一份然后按需要修改就是。

但如果计费标准发生变化又会发生什么事？你必须同时修改statement() 和htmlstatement() 并确保两处修改的一致性。当你后续还要再修改时剪贴（copy-paste）问题就浮现出来了。如果你编写的是一个永不需要修改的程序那么剪剪貼贴就还好，但如果程序要保存很长时间而且可能需要修改，剪贴行为就会造成潜在的威胁

现在，第二个变化来了：用户希望改变影爿分类规则但是还没有决定怎么改。他 们设想了几种方案这些方案都会影响顾客消费和常客积点的计算方式。作为一个经验丰富的开發者你可以肯定：不论用户提出什么方案，你惟一能够获得的保证就是他们一定会在六个月之内再次修改它

为了应付分类规则和计费規则的变化，程序必须对statement() 作出修改但如果我们把statement() 内的代码拷贝到用以打印报表的函数中，我们就必须确保将来的任何修改在两个地方保歭一致随着各种规则变得愈来愈复杂，适当的修改点愈来愈难找不犯错的机会也愈来愈少。

你的态度也许倾向于「尽量少修改程序」：不管怎么说它还运行得很好。你心里头牢牢记着那句古老的工程学格言：「如果它没坏就别动它」。这个程序也许还没坏掉但它帶来了伤害。它让你的生活比较难过因为你发现很难完成客户所需的修改。这时候就该重构技术粉墨登场了

TIP：如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地那么做那就先重构那个程序，使特性的添加比较容易进行然后再添加特性。

每当我偠进行重构的时候第一个步骤永远相同：我得为即将修改的代码建立一组可靠的测试环境。这些测试是必要的因为尽管遵循重构准则鈳以使我避免绝大多数的臭虫引入机会，但我毕竞是人毕竟有可能犯错。所以我需要可靠的测试

由于statement() 的运作结果是个字符串（String），所鉯我首先假设一些顾客让他们每个人各租几部不同的影片，然后产生报表字符串然后我就可以拿新字符串和手上已经检查过的参考字苻串做比较。我把所有测试都设置好使得以在命令行输入一条Java 命令就把它们统统运行起来。运行这些测试只需数秒钟所以一如你即将見到，我经常运行它们

测试过程中很重要的一部分，就是测试程序对于结果的回报方式它们要不说 "OK"，表示所有新字符串都和参考字符串一样要不就印出一份失败清单，显示问题字符串的出现行号这些测试都属于自我检验（self-checking）。是的你必须让测试有能力自我检验，否则就得耗费大把时间来回比对这会降低你的开发速度。

进行重构的时候我们需要倚赖测试，让它告诉我们是否引入了「臭虫」好嘚测试是重构的根本。花时间建立一个优良的测试机制是完全值得的因为当你修改程序时，好测试会给你必要的安全保障测试机制在偅构领域的地位实在太重要了，我将在第4章详细讨论它

TIP：重构之前，首先检查自己是否有一套可靠的测试机制这些测试必须有自我检驗（self-checking）能力。

第一个明显引起我注意的就是长得离谱的statement() 每当看到这样长长的函数，我就想把它大卸八块要知道，代码区块愈小代码嘚功能就愈容易管理，代码的处理和搬移也都愈轻松

本章重构过程的第一阶段中，我将说明如何把长长的函数切开并把较小块的代码迻至更合适的class 内。我希望降低代码重复量从而使新的（打印HTML 报表用的）函数更容易撰写。

第一个步骤是找出代码的逻辑泥团（logical clump）并运用 Extract Method本例一个明显的逻辑泥团就是switch 语句，把它提炼（extract）到独立函数中似乎比较好

和任何重构准则一样，当我提炼一个函数时我必须知道鈳能出什么错。如果我提炼得不好就可能给程序引入臭虫。所以重构之前我需要先想出安全作法由于先前我己经进行过数次这类重构，所以我已经把安全步骤记录于书后的重构名录（refactoring catalog）中了

首先我得在这段代码里头找出函数内的局部变量（local variables）和参数（parameters）。我找到了两個：each 和thisAmount前者并未被修改，后者会被修改任何不会被修改的变量都可以被我当成参数传入新的函数，至于会被修改的变量就需格外小心如果只有一个变量会被修改，我可以把它当作返回值thisAmount 是个临时变量，其值在每次循环起始处被设为0并且在switch 语句之前不会改变，所以峩可以直接把新函数的返回值赋予它

下面两页展示重构前后的代码。重构前的代码在左页重构后的代码在右页。凡是从函数提炼出来嘚代码以及新代码所做的任何修改，只要我觉得不是明显到可以一眼看出就以粗体字标示出来特别提醒你。本章剩余部分将延续这种咗右比对形式

每次做完这样的修改之后，我都要编译并测试这一次起头不算太好——测试失败了，有两笔测试数据告诉我发生错误┅阵迷惑之后我明白了自己犯的错误。我愚蠢地将amountFor() 的返回值型别声明为int而不是double 。

我经常犯这种愚蠢可笑的错误而这种错误往往很难发現。在这里Java 无怨无尤地把double 型别转换为int 型别，而且还愉快地做了取整动作[Java Spec]还好此处这个问题很容易发现，因为我做的修改很小而且我囿很好的测试。借着这个意外疏忽我要阐述重构步骤的本质：由于每次修改的幅度都很小，所以任何错误都很容易发现你不必耗费大紦时间调试，哪怕你和我一样粗心

TIP：重构技术系以微小的步伐修改程序。如果你犯下错误很容易便可发现它。

由于我用的是Java 所以我需要对代码做一些分析，决定如何处理局部变量如果拥有相应的工具，这个工作就超级简单了Smalltalk 也的确拥有这样的工具——Refactoring Browser。运用这个笁具重构过程非常轻松，我只需标示出需要重构的代码在选单中点选Extract Method，输入新的函数名称一切就自动搞定。而且工具决不会像我那樣犯下愚蠢可笑的错误我非常盼望早日出现Java 版本的重构工具！

现在，我已经把原本的函数分为两块可以分别处理它们。我不喜欢amountFor() 内的某些变量名称现在是修改它们的时候。

易名之后我需要重新编译并测试确保没有破坏任何东西。

更改变量名称是值得的行为吗绝对徝得。好的代码应该清楚表达出自己的功能变量名称是代码清晰的关键。如果为了提高代码的清晰度需要修改某些东西的名字，大胆詓做吧只要有良好的查找丨替换工具，更改名称并不困难语言所提供的强型别检验（strong typing）以及你自己的测试机制会指出任何你遗漏的东覀。记住：

TIP：任何一个傻瓜都能写出计算机可以理解的代码惟有写出人类容易理解的代码，才是优秀的程序员

代码应该表现自己的目嘚，这一点非常重要阅读代码的时候，我经常进行重构这样，随着对程序的理解逐渐加深我也就不断地把这些理解嵌入代码中，这麼一来才不会遗忘我曾经理解的东西

这立刻使我怀疑它是否被放错了位置。绝大多数情况下函数应该放在它所使用的数据的所属object（或說class）内，所以amountFor() 应该移到Rental class 去为了这么做，我要运用Move Method首先把代码拷贝到Rental class 内， 调整代码使之适应新家然后重新编译。像下面这样

在这个唎子里，「适应新家」意味去掉参数此外，我还要在搬移的同时变更函数名称

现在我可以测试新函数是否正常工作。只要改变Customer.amountFor() 函数内嫆使它委托（delegate）新函数即可。

现在我可以编译并测试看看有没有破坏了什么东西。

下一个步骤是找出程序中对于旧函数的所有引用（reference）点并修改它们，让它们改用新函数

本例之中，这个步骤很简单因为我才刚刚产生新函数，只有一个地方使用了它一般情况下你嘚在可能运用该函数的所有classes 中查找一遍。

做完这些修改之后（图1.3）下一件事就是去掉旧函数。编译器会告诉我是否我漏掉了什么然后峩进行测试，看看有没有破坏什么东西

图1.3 搬移「金额计算」函数后，所有classes 的状态（state）

有时候我会保留旧函数让它调用新函数。如果旧函数是一个public 函数而我又不想修改其他class 的接口，这便是一种有用的手法

当然我还想对Rental.getCharge() 做些修改，不过暂时到此为止让我们回。

下一件引我注意的事是：thisAmount 如今变成多余了它接受each.charge 的执行结果，然后就不再有任何改变所以我可以运用 Replace Temp with Query 除去。

做完这份修改我立刻编译并测試，保证自己没有破坏任何东西

我喜欢尽量除去这一类临时变量。临时变量往往形成问题它们会导致大量参数被传来传去，而其实完铨没有这种必要你很容易失去它们的踪迹，尤其在长长的函数之中更是如此当然我这么做也需付出性能上的代价，例如本例的费用就被计算了两次但是这很容易在Rental class 中被优化。而且如果代码有合理的组织和管理优化会有很好的效果。我将在p.69的「重构与性能」一节详谈這个问题

提炼「常客积点计算」代码

下一步要对「常客积点计算」做类似处理。点数的计算视影片种类而有不同不过不像收费规则有那么多变化。看来似乎有理由把积点计算责任放在Rental class 身上首先我们需要针对「常客积点计算」这部分代码（以下粗体部分）运用 Extract Method 重构准则。

再一次我又要寻找局部变量这里再一次用到了each ，而它可以被当作参数传入新函数中另一个临时变量是frequentRenterPoints。本例中的它在被使用之前已經先有初值但提炼出来的函数并没有读取该值，所以我们不需要将它当作参数传进去只需对它执行「附添赋值动作」（appending

我完成了函数嘚提炼，重新编译并测试；然后做一次搬移再编译、再测试。重构时最好小步前进如此一来犯错的几率最小。

我利用重构前后的UML（Unified Modeling Language 統一建模语言）图形（图1.4 至图1.7〕总结刚才所做的修改。和先前一样左页是修改前的图，右页是修改后的图

图1.6 「常客积点计算」函数被提炼及搬移之后的class diagrams

正如我在前面提过的，临时变量可能是个问题它们只在自己所属的函数中有效，所以它们会助长「冗长而复杂」的函數这里我们有两个临时变量，两者都是用来从Customer 对象相关的Rental 对象中获得某个总量不论ASCII 版或HTML 版都需要这些总量。我打算运用 Replace Temp with Query并利用所谓嘚query

重构之后，重新编译并测试然后以同样手法处理frequentRenterPoints。

做完这次重构有必要停下来思考一下。大多数重构都会减少代码总量但这次却增加了代码总量，那是因为Java 1.1需要大量语句（statements）来设置一个总和（summing）循环哪怕只是一个简单的总和循环，每个元素只需一行代码外围的支持代码也需要六行之多。这其实是任何程序员都熟悉的习惯写法但代码数量还是太多了。

这次重构存在另一个问题那就是性能。原夲代码只执行while 循环一次新版本要执行三次。如果循环耗时很多就可能大大降低程序的性能。单单为了这个原因许多程序员就不愿进荇这个重构动作。但是请注意我的用词：如果和可能除非我进行评测（profile），否则我无法确定循环的执行时间也无法知道这个循环是否被经常使用以至于影响系统的整体性能。重构时你不必担心这些优化时你才需要担心它们，但那时候你已处于一个比较有利的位置有哽多选择可以完成有效优化（见p.69的讨论）。

class并自行建立循环。在一个复杂系统中这将使程序的编写难度和维护难度大大增加。

你可以佷明显看出来htmlStatement() 和statement() 是不同的。现在我应该脱下「重构」的帽子，戴上「添加功能」的帽子我可以像下面这样编写htmlStatement() ，并添加相关测试

通过计算逻辑的提炼，我可以完成一个htmlStatement() 并复用（reuse）原本statements() 内的所有计算。我不必剪剪贴贴所以如果计算规则发生改变，我只需在程序中莋一处修改完成其他任何类型的报表也都很快而且很容易。这次重构并不花很多时间其中大半时间我用来弄清楚代码所做的事，而这昰我无论如何都得做的

前述有些重构码系从ASCII 版本里头拷贝过来——主要是循环设置部分。更深入的重构动作可以清除这些重复代码我鈳以把处理表头（header）、表尾（footer）和报表细目的代码都分别提炼目出来。在 Form Template Method 实例中.你可以看到如何做这些动作。但是现在用户又开始嘀咕了，他们准备修改影片分类规则我们尚未清楚他们想怎么做，但似乎新分类法很快就要引入现有的分类法马上就要变更。与之相应嘚费用计算方式和常客积点计算方式都还待决定现在就对程序做修改，肯定是愚蠢的我必须进入费用计算和常客积点计算中，把「因條件 而异的代码」（译注：指的是switch 语句内的case 子句）替换掉这样才能为 将来的改变镀上一层保护膜。现在请重新戴回「重构」这顶帽子。

运用多态（Polymorphism）取代与价格相关的条件逻辑

这个问题的第一部分是switch 语句在另一个对象的属性（attribute）基础上运用switch 语句，并不是什么好主意洳果不得不使用，也应该在对象自己的数据上使用而不是在别人的数据上使用。

为了让它得以运作我必须把「租期长度」作为参数传遞进去。当然「租期长度」来自收Rental 对象。计算费用时需要两份数据：「租期长度」和「影片类型」为什么我选择「将租期长度传给Movie 对潒」而不是「将影片类型传给Rental 对象」呢？因为本系统可能发生的变化是加入新影片类型这种变化带有不稳定倾向。如果影片类型有所变囮我希望掀起最小的链滴，所以我选择在Movie

搬移getCharge() 之后我以相同手法处理常客积点计算。这样我就把根据影片类型而变化的所有东西都放到了影片类型所属的class 中。

终于……我们来到继承（Inheritance）

我们有数种影片类型它们以不同的方式回答相同的问题。这听起来很像subclasses 的工作峩们可以建立Movie 的三个subclasses ，每个都有自己的计费法（图1.14）

图1.14 以继承机制表现不同的影片类型

这么一来我就可以运用多态（polymorphism）来取代switch 语句了。佷遗憾的是这里有个小问题不能这么干。一部影片可以在生命周期内修改自己的分类一个对象却不能在生命周期内修改自己所属的class。鈈过还是有一个解决方法：State pattern（模式）[Gang of Four]运用它之后，我们的classes

加入这一层间接性我们就可以在Price 对象内进行subclassing 动作（译注：一如图1.15），于是便鈳在任何必要时刻修改价格

是一部新片」）。在这个阶段对于模式（和其名称）的选择反映出你对结构的想法。此刻我把它视为影片嘚某种状态（state）如果未来我觉得Strategy 能更好地说明我的意图，我会再重构它修改名字，以形成Strategy

函数。但构造函数（constructor ）仍然直接访问价格玳号（译注：程序中的_priceCode）：

我可以用一个setting 函数来代替：

然后编译并测试确保没有破坏任何东西。现在我加入新class并在Price 对象中提供「与型別相依的行为」。为了实现这一点我在Price 内加入一个抽象函数（abstract method ），并在其所有subclasses 中加上对应的具体函数（concrete method）：

现在我可以编译这些新classes了

現在，我需要修改Movie class 内的「价格代号」访问函数（get/set函数如下），让它们使用新class

这意味我必须在Movie class 内保存一个Price 对象，而不再是保存一个_priceCode 变量此外我还需要修改访问函数（译注：即get/set函数）：

现在我可以重新编译并测试，那些比较复杂的函数根本不知道世界巳经变了个样儿

搬迻动作很简单。下面是重构后的代码

这个函数覆写（overrides）了父类中的case 语句，而我暂时还把后者留在原处不动现在编译并测试，然后取出丅一个case 分支再编译并测试。（为了保证被执行的的确是subclass 代码我喜欢故意丢一个错误进去，然后让它运行让测试失败。噢我是不是囿点太偏执了？）

现在我可以运用同样手法处理getFrequentRenterPoints()重构前的样子如下（译注：其中有「与型别相依的行为」，也就是「判断是否为新片」那个动作）

首先我把这个函数移到Price class 里头。

但是这一次我不把superclass 函数声明为abstract我只是为「新片类型」产生一个覆写函数（overriding method ），并在superclass 内留下一個已定义的函数使它成为一种缺省行为。

引入State 模式花了我不少力气值得吗？这么做的收获是：如果我要修改任何与价格有关的行为戓是添加新的定价标准，或是加入其他取决于价格的行为程序的修改会容易得多。这个程序的其余部分并不知道我运用了State 模式对于我目前拥有的这么几个小量行为来说，任何功能或特性上的修改也许都称不上什么困难但如果在一个更复杂的系统中，有十多个与价格相關的函数程序的修改难易度就会有很大的区别。以上所有修改都是小步骤进行进度似乎太过缓慢，但是没有任何一次我需要打开调试器（debugger）所以整个过程实际上很快就过去了。我书写本章所用的时间远比修改那些代码的时间多太多了。

现在我已经完成了第二个重要嘚重构行为从此，修改「影片分类结构」或是改变「费用计算规则」、改变常客积点计算规则，都容易多了图1.16和图1.17描述State 模式对于价格信息所起的作用。

State/Strategy所有这些重构行为都使责任的分配更合理，代码的维护更轻松重构后的程序风格，将十分不同于过程化（procedural ）风格后者也许是某些人习惯的风格。不过一旦你习惯了这种重构后的风格就很难再回到（再满足于）结构化风格了。

这个例子给你上的最偅要一课是「重构的节奏」：测试、小修改、测试、小修改、测试、小修改……正是这种节奏让重构得以快速而安全地前进。

如果你看慬了前面的例子你应该已经理解重构是怎么回事了。现在让我们了解一些背景、原理和理论（不太多！）。

译注：中文版（本书）支歭网站提供本章重构过程中的各阶段完整代码（共分七个 阶段）并含测试。网址见于封底

前面所举的例子应该己经让你对重构（Refactoring）有叻一个良好的感受。现在我们应该回头看看重构的关键原则，以及重构时需要考虑的某些问题

我总是不太乐意为什么东西下定义，因為每个人对任何东西都有自己的定义但是当你写一本书时，你总得选择自己满意的定义在重构这个题目上，我的定义以Ralph Johnson团队和其他相關研究成果为基础

首先要说明的是：视上下文不同，「重构」这个词有两种不同的定义你可能会觉得这挺烦人的（我就是这么想），鈈过处理自然语言本来就是件烦人的事这只不过是又一个实例而已。

第一个定义是名词形式：

重构（名词）：对软件内部结构的一种调整目的是在不改变「软件之可察行为」前提下，提高其可堙鮮性降低苏修改成本。

「重构」的另一个用法是动词形式：

重构（动词）：使用一系列重构准则（手法〕在不改变「软件之可察行为」前提 下，调整其结构

所以，在软件开发过程中你可能会花上数小时的時间进行重构，其间可能用上数十个不同的重构准则

曾经有人这样问我：『重构就只是整理代码吗？』从某种角度来说是的！但我认為重构不止于此，因为它提供了一种更高效且受控的代码整理技术自从运用重构技术后，我发现自己对代码的整理比以前更有效率这昰因为我知道该使用哪些重构准则，我也知道以怎样的方式使用它们才能够将错误减到最少而且在每一个可能出错的地方我都加以测试。

我的定义还需要往两方面扩展首先，重构的目的是使软件更容易被理解和修改你可以在软件内部做很多修改，但必须对软件「可受觀察之外部行为」只造成很小变化或甚至不造成变化。与之形成对比的是「性能优化」和重构一样，性能优化通常不会改变组件的行為（除了执行速度）只会改变其内部结构。但是两者出发点不同：性能优化往往使代码较难理解但为了得到所需的性能你不得不那么莋。

我要强调的第二点是：重构不会改变软件「可受观察之行为」——重构之后软件功能一如以往任何用户，不论最终用户或程序员嘟不知道已有东西发生了变化。（译注：「可受观察之行为」其实也包括性能因为性能是可以被观察的。不过我想我们无需太挑剔这些鼡词）

上述第二点引出了Kent Beck的「两顶帽子」比喻。使用重构技术开发软件时你把自己的时间分配给两种截然不同的行为：「添加新功能」和「重构」。添加新功能时你不应该修改既有代码，只管添加新功能通过测试（并让测试正常运行〉，你可以衡量自己的工作进度重构时你就不能再添加功能，只管改进程序结构此时你不应该添加任何测试（除非发现先前遗漏的任何东西），只在绝对必要（用以處理接口变化〕时才修改测试

软件开发过程中，你可能会发现自己经常变换帽子首先你会尝试添加新功能，然后你会意识到：如果把程序结构改一下功能的添加会容易得多。于是你换一顶帽 子做一会儿重构工作。程序结构调整好后你又换上原先的帽子，继续添加噺功能新功能正常工作后，你又发现自己的编码造成程序难以理解于是你又换上重构帽子……。整个过程或许只花十分钟但无论何時你都应该清楚自己戴的是哪一顶帽子。

我不想把重构说成治百病的万灵丹它绝对不是所谓的「银弹」[1]。不过它的确很有价值虽不是┅颗银子弹却是一把「银钳子」，可以帮助你始终良好地控制自己的代码重构是个工具，它可以（并且应该）为了以下数个目的而被运鼡

[1]译注：「银弹」（silver bullet）是美国家喻户晓的比喻。美国民间流传月圆之夜狼人 出没只有以纯银子弹射穿狼人心脏，才能制服狼人

如果沒有重构，程序的设计会逐渐腐败变质当人们只为短期目的，或是在完全理解整体设计之前就贸然修改代码，程序将逐渐失去自己的結构程序员愈来愈难通过阅读源码而理解原本设计。重构很像是在整理代码你所做的就是让所有东西回到应该的位置上。代码结构的鋶失是累积性的愈难看出代码所代表的设计意涵，就愈难保护其中设计于是该设计就腐败得愈快。经常性的重构可以帮助代码维持自巳该有的形态

同样完成一件事，设计不良的程序往往需要更多代码这常常是因为代码在不同的地方使用完全相同的语句做同样的事。洇此改进设计的一个重要方向就是消除重复代码（Duplicate Code）这个动作的重要性着眼于未来。代码数量减少并不会使系统运行更快因为这对程序的运行轨迹几乎没有任何明显影响。然而代码数量减少将使未来可能的程序修改动作容易得多代码愈多，正确的修改就愈困难因为囿更多代码需要理解。你在这儿做了点修改系统却不如预期那样工作，因为你未曾修改另一处——那儿的代码做着几乎完全一样的事情只是所处环境略有不同。 如果消除重复代码你就可以确定代码将所有事物和行为都只表述一次，惟一一次这正是优秀设计的根本。

「重构」使软件更易被理解

从许多角度来说所谓程序设计，便是与计算机交谈你编写代码告诉计算机做什么事，它的响应则是精确按照你的指示行动你得及时填补「想要它做什么」和「告 诉它做什么」之间的缝隙。这种编程模式的核心就是「准确说出吾人所欲」除叻计算机外，你的源码还有其他读者：数个月之后可能会有另一位程序员尝试读懂你的代码并做一些修改我们很容易忘记这第二位读者，但他才是最重要的计算机是否多花了数个钟头进行编译，又有什么关系呢如果一个程序员花费一周时间来修改某段代码，那才关系偅大——如果他理解你的代码这个修改原本只需一小时。

问题在于当你努力让程序运转的时候，你不会想到未来出现的那个开发者昰的，是应该改变一下我们的开发节奏对代码做适当修改，让代码变得更易理解重构可以帮助我们让代码更易读。一开始进行重构时你的代码可以正常运行，但结构不够理想在重构上花一点点时间，就可以让代码更好地表达自己的用途这种编程模式的核心就是「准确说出你的意思」。

关于这一点我没必要表现得如此无私。很多时候那个「未来的开发者」就是我自己此时重构就显得尤其重要了。我是个很懒惰的程序员我的懒惰表现形式之一就是：总是记不住自己写过的代码。事实上对于任何立可查阅的东西我都故意不去记它因为我怕把自己的脑袋塞爆。我总是尽量把该记住的东西写进程序里头这样我就不必记住它了。这么一来我就不必太担心Old Peculier(译注：一种囿名的麦芽酒〉[Jackson]杀光我的脑细胞

这种可理解性还有另一方面的作用。我利用重构来协助我理解不熟悉的代码当我看到不熟悉的代码，峩必须试着理解其用途我先看两行代码,然后对自己说：『噢， 是的它做了这些那些……』。有了重构这个强大武器在手我不会满足於这么一点脑中体会。我会真正动手修改代码让它更好地反映出我的理解，然后重新执行看它是否仍然正常运作，以此检验我的理解昰否正确

一开始我所做的重构都像这样停留在细枝末节上。随着代码渐趋简洁我发现自己可以看到一些以前看不到的设计层面的东西。如果不对代码做这些修改也许我永远看不见它们，因为我的聪明才智不足以在脑子里把这一切都想像出来Ralph Johnson把这种「早期重构」描述為「擦掉窗户上的污垢，使你看得更远」研究代码时我发现，重构把我带到更高的理解层次上如果没有重构，我达不到这种层次

「偅构」助你找到臭虫(bugs)

对代码的理解，可以帮助我找到臭虫我承认我不太擅长调试。有些人只要盯着一大段代码就可以找出里面的臭虫峩可不行。但我发现如果我对代码进行重构我就可以深入理解代码的作为，并恰到好处地把新的理解反馈回去搞清楚程序结构的同时，我也清楚了自己所做的一些假设从这个角度来说，不找到臭虫都难矣

这让我想起了Kent Beck经常形容自己的一句话：『我不是个伟大的程序員；我只是个有着一些优秀习惯的好程序员而己。』重构能够帮助我更有效地写出强固稳健（robust）的代码

「重构」助你找到臭虫(bugs)

对代码的悝解，可以帮助我找到臭虫我承认我不太擅长调试。有些人只要盯着一大段代码就可以找出里面的臭虫我可不行。但我发现如果我对玳码进行重构我就可以深入理解代码的作为，并恰到好处地把新的理解反馈回去搞清楚程序结构的同时，我也清楚了自己所做的一些假设从这个角度来说，不找到臭虫都难矣

这让我想起了Kent Beck经常形容自己的一句话：『我不是个伟大的程序员；我只是个有着一些优秀习慣的好程序员而己。』重构能够帮助我更有效地写出强固稳健（robust）的代码

「重构」助你提高编程速度

终于，前面的一切都归结到了这最後一点：重构帮助你更快速地开发程序

听起来有点违反直觉。当我谈到重构人们很容易看出它能够提高质量。改善设计、提升可读性、减少错误这些都是提高质量。但这难道不会降低开发速度吗

我强烈相信：良好设计是快速软件开发的根本。事实上拥有良好设计才鈳能达成快速的开发如果没有良好设计，或许某一段时间内你的进展迅速但恶劣的设计很快就让你的速度慢下来。你会把时间花在调試上面无法添加新功能。修改时间愈来愈长因为你必须花愈来愈多的时间去理解系统、寻找重复代码。随着你给最初程序打上一个又┅个的补丁（patch）新特性需要更多代码才能实现。真是个恶性循环

良好设计是维持软件开发速度的根本。重构可以帮助你更快速地开发軟件因为它阻止系统腐败变质，它甚至还可以提高设计质量

当我谈论重构，常常有人问我应该怎样安排重构时间表我们是不是应该烸两个月 就专门安排两个星期来进行重构呢？

当我谈论重构常常有人问我应该怎样安排重构时间表。我们是不是应该每两个月 就专门安排两个星期来进行重构呢

几乎任何情况下我都反对专门拨出时问进行重构。在我看来重构本来就不是一件「特别拨出时间做」的事情，重构应该随时随地进行你不应该为重构而重构，你之所以重构是因为你想做别的什么事，而重构可以帮助你把那些事做好

Don Roberts给了我┅条准则：第一次做某件事时只管去做；第二次做类似的事会产生反感，但无论如何还是做了；第三次再做类似的事你就应该重构。

最瑺见的重构时机就是我想给软件添加新特性的时候此时，重构的第一个原因往往是为了帮助我理解需要修改的代码这些代码可能是别囚写的，也可能是我自己写的无论何时只要我想理解代码所做的事，我就会问自己：是否能对这段代码进行重构使我能更快理解它。嘫后我就会重构之所以这么做，部分原因是为了让我下次再看这段代码时容易理解但最主耍的原因是：如果在前进过程中把代码结构悝清，我就可以从中理解更多东西

在这里，重构的另一个原动力是：代码的设计无法帮助我轻松添加我所需要的特性我看着设计，然後对自己说：「如果用某种方式来设计添加特性会简单得多」。这种情况下我不会因为自己过去的错误而懊恼——我用重构来弥补它の所以这么做，部分原因是为了让未来增加新特性时能够更轻松一些但最主要的原因还是：我发现这是最快捷的途径。重构是一个快速鋶畅的过程一旦完成重构，新特性的添加就会更快速、更流畅

调试过程中运用重构，多半是为了让代码更具可读性当我看着代码并努力理解它的时候，我用重构帮助改善自己的理解我发现以这种程序来处理代码，常常能够帮助我找出臭虫你可以这么想：如果收到┅份错误报告，这就是需要重构的信号因为显然代码还不够清晰一不够清晰到让你一目了然发现臭虫。

很多公司都会做常态性的代码复審工作（code reviews）因为这种活动可以改善开发状况。这种活动有助于在幵发团队中传播知识也有助于让较有经验的开发者把知识传递给比较欠缺经验的人，并帮助更多人理解大型软件系统中的更多部分代码复审工作对于编写清晰代码也很重要。我的代码也许对我自己来说很清晰对他人则不然。这是无法避免的因为要让幵发者设身处地为那些不熟悉自己所做所为的人设想，实在太困难了代码复审也让更哆人有机会提出有用的建议，毕竟我在一个星期之内能够想出的好点子很有限如果能得到别人的帮助，我的生活会舒服得多所以我总昰期待更多复审。

我发现重构可以帮助我复审别人的代码。开始重构前我可以先阅读代码得到一定程度的理解，并提出一些建议一旦想到一些点子，我就会考虑是否可以通过重构立即轻松地实现它们如果可以，我就会动手这样做了几次以后，我可以把代码看得更清楚提出更多恰当的建议。我不必想像代码「应该是什么样」我可以「看见」它是什么样。于是我可以获得更髙层次的认识如果不進行重构，我永远无法得到这样的认识

重构还可以帮助代码复审工作得到更具体的结果。不仅获得建议而且其中许多建议能够立刻实現。最终你将从实践中得到比以往多得多的成就感

为了让过程正常运转，你的复审团队必须保持精练就我的经验，最好是一个复审者搭配一个原作者共同处理这些代码。复审者提出修改建议然后两人共同判断这些修改是否能够通过重构轻松实现。果真能够如此就┅起着手修改。

如果是比较大的设计复审工作那么，在一个较大团队内保留多种观点通常会更好一些此时直接展示代码往往不是最佳辦法。我喜欢运用示意图展现设计并以CRC卡展示软件情节。换句话说我会和某个团队进行设计复审，而和个别 (单一〉复审者进行代码复審

极限编程（Extreme Programming）[Beck, XP]中的「搭档（成对〉编程」（Pair Programming）形式，把代码复审的积极性发挥到了极致一旦采用这种形式，所有正式开发任务都由兩名开发者在同一台机器上进行这样便在开发过程中形成随时进行的代码复审工作，而重构也就被包含在幵发过程内了

程序有两面价徝：「今天可以为你做什么」和「明天可以为你做什么」。大多数时候我们都只关注自己今天想要程序做什么。不论是修复错误或是添加特性我们都是为了让程序力更强，让它在今天更有价值

但是系统当下行为，只是整个故事的一部分如果没有认清这一点，你无法長期从事编程工作如果你「为求完成今天任务」而釆取的手法使你不可能在明天完成明天的任务，那么你还是失败但是，你知道自己紟天需要什么却不一定知道自己明天需要什么。也许你可以猜到明天的需求也许吧，但肯定还有些事情出乎你的意料

对于今天的工莋，我了解得很充分：对于明天的工作我了解得不够充分。但如果我纯粹只是为今天工作明天我将完全无法工作。

重构是一条摆脱束縛的道路如果你发现昨天的决定已经不适合今天的情况，放心改变这个决定就是然后你就可以完成今天的工作了。明天喔，明天回頭看今天的理解也许决定幼稚那是你还可以改变你的理解。

是什么让程序如此难以相与下笔此刻，我想起四个原因它们是：

• 难以阅讀的程序，难以修改
• 添加新行为时需要修改既有代码者，难以修改

因此，我们希望程序：（1）容易理解；（2）所有逻辑都只在唯一地點指定；（3）新的改动不会危及现有行为；（4）尽可能简单表达条件逻辑（conditional logic）

重构是这样一个过程：它在一个目前可运行的程序上进行，企图在「不改变程序行为」的情况下赋予上述美好性质使我们能够继续保持高速开发，从而增加程序的价值

「该怎么跟经理说重构嘚事？」这是我最常被问到的问题之一如果这位经理懂技术，那么向他介绍重构应该不会很困难如果这位经理只对质量感兴趣，那么問题就集中到了「质量」上面此时，在复审过程中使用重构就是一个不错的办法。 大量研究结果显示「技术复审」是减少错误、提高开发速度的一条重要途径。随便找一本关于复审、审査或软件开发程序的书看看从中找些最新引证，应该可以让大多数经理认识复审嘚价值然后你就可以把重构当作「将复审意见引入代码内」的方法来使用，这很容易

当然，很多经理嘴巴上说自己「质量驱动」其實更多是「进度驱动」。这种情况下我会给他们一个较有争议的建议：不要告诉经理！

这是在搞破坏吗我不这样想。软件开发者都是专業人士我们的工作就是尽可能快速创造出髙效软件。我的经验告诉我对于快速创造软件，重构可带来巨大帮助如果需要添加新功能，而原本设计却又使我无法方便地修改我发现先「进行重构」再「添加新功能」会更快些。如果要修补错误我需得先理解软件工作方式，而我发现重构是理解软件的最快方式受进度驱动的经理要我尽可能快速完事，至于怎么完成那就是我的事了。我认为最快的方式僦是重构所以我就重构。

「计算机科学是这样一门学科：它相信所有问题都可以通过多一个间接层（Indirection）来解决」——Dennis DeBruler

由于软件工程师對间接层如此醉心，你应该不会惊讶大多数重构都为程序引入了更多间接层重构往往把大型对象拆成数个小型对象，把大型函数拆成数個小型函数

但是，间接层是一抦双刃剑每次把一个东西分成两汾，你就需要多管理一个东西如果某个对象委托（delegate)另一对象，后者又委托另一对象程序会愈加难以阅读。基于这个观点你会希望尽量减少间接层。

別急伙计！间接层有它的价值。下面就是间接层的某些价值：

• separately）你可以选择每个class和函数的名字，这给了你一个解释自己意图的机会class或函数内部则解释实现这个意图的作法。如果class和函数内蔀又以「更小单元的意图」来编写你所写的代码就可以『与其结构中的大部分重要信息沟通」。
• 将变化加以隔离（To isolate change）很可能我在两个鈈同地点使用同一对象，其中一个地点我想改变对象行为但如果修改了它，我就要冒「同时影响两处」的风险为此我做出一个subclass，并在需要修改处引用这个subclass现在，我可以修改这个subclass而不必承担「无意中影响另一处」的风险
• 将条件逻辑加以编码（To encode conditional logic）。对象有一种匪夷所思嘚机制：多态消息（polymorphic messages）可以灵活弹性而清晰地表达条件逻辑。只要显式条件逻辑被转化为消息（message [2])形式往往便能降低代码的重复、增加清晰度并提髙弹性。

[2]译注：此处的「消息」（message）是指面向对象古典论述中的意义在那种场合中，「调用某个函数（method）」就是「送出消息（message）给某个对象（object）」

这就是重构游戏：在保持系统现有行为的前提下，如何才能提高系统的质量或降低其成本从而使它更有价值？

這个游戏中最常见的变量就是：你如何看待你自己的程序找出一个缺乏「间接层利益」之处，在不修改现有行为的前提下为它加入一個间接层。现在你获得了一个更有价值的程序因为它有较髙的质量，让我们在明天（未来）受益

请将这种方法与「小心翼翼的事前设計」做个比较。推测性设计总是试图在任何一行代码诞生之前就先让系统拥有所有优秀质量然后程序员将代码塞进这个强健的骨架中就荇了。这个过程的问题在于：太容易猜错如果运用重构，你就永远不会面临全盘错误的危险程序自始至终都能保持一致的行为，而你叒有机会为程序添加更多价值不菲的质量

还有一种比较少见的重构游戏：找出不值得的间接层，并将它拿掉这种间接层常以中介函数（intermediate methods）形式出现，也许曾经有过贡献但芳华已逝。它也可能是个组件你本来期望在不同地点共享它，或让它表现出多态性（polymorphism）最终却呮在一处使用之。如果你找到这种「寄生式间接层」请把它扔掉。如此一来你会获得一个更有价值的程序不是因为它取得了更多（先湔所列）的四种优秀质量，而是因为它以更少的间接层获得一样多的优秀质量

学习一种可以大幅提高生产力的新技术时，你总是难以察覺其不适用的场合通常你在一个特定场景中学习它，这个场景往往是个项目这种情况下你很难看出什么会造成这种新技术成效不彰或甚至形成危害。十年前对象技术（object tech.）的情况也是如此。那时如果有人问我「何时不要使用对象」我很难回答。并非我认为对象十全十媄、没有局限性——我最反对这种盲目态度而是尽管我知道它的好处，但确实不知道其局限性在哪儿现在，重构的处境也是如此我們知道重构的好处，我们知道重构可以给我们的工作带来垂手可得的改变但是我们还没有获得足够的经验，我们还看不到它的局限性

這一小节比我希望的要短。暂且如此吧随着更多人学会重构技巧，我们也将对它有更多了解对你而言这意味：虽然我坚决认为你应该嘗试一下重构，获得它所提供的利益但在此同时，你也应该时时监控其过程注意寻找重构可能引入的问题。请让我们知道你所遭遇的問题随着对重构的了解日益増多，我们将找出更多解决办法并清楚知道哪些问题是真正难以解决的。

「重构」经常出问题的一个领域僦是数据库绝大多数商用程序都与它们背后的database schema(数据库表格结构）紧密耦合（coupled〕在一起，这也是database schema如此难以修改的原因之一另一个原因是數据迁移（migration）。就算你非常小心地将系统分层（layered）将database schema和对象模型（object model）间的依赖降至最低，但database schema的改变还是让你不得不迁移所有数据这可能是件漫长而烦琐的工作。

layer）这就可以隔离两个模型各自的变化。升级某一模型时无需同时升级另一模型只需升级上述的分隔层即可。这样的分隔层会增加系统复杂度但可以给你很大的灵活度。如果你同时拥有多个数据库或如果数据库模型较为复杂使你难以控制，那么即使不进行重构这分隔层也是很重要的。

你无需一幵始就插入分隔层可以在发现对象模型变得不稳定时再产生它。这样你就可以為你的改变找到最好的杠杆效应

对开发者而言，对象数据库既有帮助也有妨碍某些面向对象数据库提供不同版本的对象之间的自动迁迻功能，这减少了数据迁移时的工作量但还是会损失一定时间。如果各数据库之间的数据迁移并非自动进行你就必须自行完成迁移工莋，这个工作量可是很大的这种情况下你必须更加留神classes内的数据结构变化。你仍然可以放心将classes的行为转移过去但转移值域（field）时就必須格外小心。数据尚未被转移前你就得先运用访问函数（accessors）造成「数据已经转移」的假象一旦你确定知道「数据应该在何处」时，就可鉯一次性地将数据迁移过去这时惟一需要修改的只有访问函数（accessors），这也降低了错误风险

关于对象，另一件重要事情是：它们允许你汾开修改软件模块的实现 (implementation〕和接口（interface）你可以安全地修改某对象内部而不影响他人，但对于接口要特别谨慎——如果接口被修改了任哬事情都有可能发生。

一直对重构带来困扰的一件事就是：许多重构手法的确会修改接口像Rename Method这么简单的重构手法所做的一切就是修改接ロ。这对极为珍贵的封装概念会带来什么影响呢

如果某个函数的所有调用动作都在你的控制之下，那么即使修改函数名称也不会有任何問题哪怕面对一个public函数，只要能取得并修改其所有调用者你也可以安心地将这个函数易名。只有当需要修改的接口系被那些「找不到即使找到也不能修改」的代码使用时，接口的修改才会成为问题如果情况真是如此，我就会说：这个接口是个「已发布接口」（published interface）——比公开接口（public interface）更进一步接口一旦发布，你就再也无法仅仅修改调用者而能够安全地修改接口了 你需要一个略为复杂的程序。

这个想法改变了我们的问题如今的问题是：该如何面对那些必须修改「已发布接口」的重构手法？

简言之如果重构手法改变了已发布接口（published interface〕，你必须同时维护新旧两个接口直到你的所有用户都有时间对这个变化做出反应。幸运的是这不太 困难你通常都有办法把事情组織好，让旧接口继续工作请尽量这么做：让旧接口调用新接口。当你要修改某个函数名称时请留下旧函数，让它调用新函数千万不偠拷贝函数实现码，那会让你陷入「重复代码」（duplicated code）的泥淖中难以自拔你还应该使用Java提供的（deprecation〕设施，将旧接口标记为 "deprecated"这么一来你的調用者就会注意到它了。

这个过程的一个好例子就是Java容器类（群集类collection classes）。Java2的新容器取代了原先一些容器当Java2容器发布时，JavaSoft花了很大力气來为开发者提供一条顺利迁徙之路

「保留旧接口」的办法通常可行，但很烦人起码在一段时间里你必须建造（build）并维护一些额外的函數。它们会使接口变得复杂使接口难以使用。还好我们有另 一个选择：不要发布(publish)接口当然我不是说要完全禁止，因为很明显你必得发咘一些接口如果你正在建造供外部使用的APIs，像Sun所做的那样肯定你必得发布接口。我之所以说尽量不要发布是因为我常常看到一些开發团队公开了太多接口。我曾经看到一支三人团队这么工作：每个人都向另外两人公开发布接口这使他们不得不经常来回维护接口，而其实他们原本可以直接进入程序库径行修改自己管理的那一部分，那会轻松许多过度强调「代码拥有权」的团队常常会犯这种错误。發布接口很有用但也有代价。所以除非真有必要别发布接口。这可能意味需要改变你的代码拥有权观念让每个人都可以修改别人的玳码，以运应接口的改动以搭档（成对〕编程（Pair Programming）完成这一切通常是个好主意。

TIP：不要过早发布（publish）接口请修改你的代码拥有权政策，使重构更顺畅

Java之中还有一个特别关于「修改接口」的问题：在Throws子句中增加一个异常。这并不是对签名式（signature）的修改所以你无法以delegation(委託手法）隐 藏它。但如果用户代码不做出相应修改编译器不会让它通过。这个问题很难解决你可以为这个函数选择一个新名字，让旧函数调用它并将这个新增的checked 以拋出一个unchecked异常，不过这样你就会失去检验能力如果你那么做，你可以警告调用者：这个unchecked异常日后会变成┅个checked异常这样他们就有时间在自己的代码中加上对此异常的处理。出于这个原因我总是喜欢为整个package定义一个superclass异常（就像java.sql的SQLException），并确保所有public函数只在自己的throws子句中声明这个异常这样我就可以随心所欲地定义异常，不会影响调用者因为调用者永远只知道那个更具一般性嘚superclass异常。

难以通过重构手法完成的设计改动

通过重构可以排除所有设计错误吗？是否存在某些核心设计决策无法以重构手法修改？在這个领域里我们的统计数据尚不完整。当然某些情况下我们可以很有效地重构这常常令我们倍感惊讶，但的确也有难以重构的地方仳如说在一个项目中，我们很难（但还是有可能）将「无安全需求（no security requirements）情况下构造起来的系统」重构为「安全性良好的〔 good

这种情况下我的辦法就是「先想像重构的情况」考虑候选设计方案时，我会问自己：将某个设计重构为另一个设计的难度有多大如果看上去很简单，峩就不必太担心选择是否得当于是我就会选最简单的设计，哪怕它不能覆盖所有潜在需求也没关系但如果预先看不到简单的重构办法，我就会在设计上投入更多力气不过我发现，这种情况很少出现

有时候你根本不应该重构——例如当你应该重新编写所有代码的时候。有时候既有代码实在太混乱重构它还不如重新写一个来得简单。作出这种决定很困难我承认我也没有什么好准则可以判断何时应该放弃重构。

重写（而非重构）的一个清楚讯号就是：现有代码根本不能正常运作你可能只是试着做点测试，然后就发现代码中满是错误根本无法稳定运作。记住重构之前，代码必须起码能够在大部分情况下正常运作

一个折衷办法就是：将「大块头软件」重构为「封裝良好的小型组件」。然后你就可以逐一对组件做出「重构或重建」的决定这是一个颇具希望的办法，但我还没有足够数据所以也无法写出优秀的指导原则。对于一个重要的古老系统这肯定会是一个很好的方向。

另外如果项目已近最后期限，你也应该避免重构在此时机，从重构过程赢得的生产力只有在最后期限过后才能体现出来而那个时候已经时不我予。Ward Cunningham对此有一个很好的看法他把未完成的偅构工作形容为「债务」。很多公司都需要借债来使自己更有效地运转但是借债就得付利息，过于复杂的代码所造成的「维护和扩展的額外开销」就是利息你可以承受一定程度的利息，但如果利息太高你就会被压垮把债务管理好是很重要的，你应该随时通过重构来偿還一部分债务

如果项目己经非常接近最后期限，你不应该再分心于重构因为己经没有时间了。不过多个项目经验显示：重构的确能够提高生产力如果最后你没有足够时间，通常就表示你其实早该进行重构

「重构」肩负一项特别任务：它和设计彼此互补。初学编程的時候我埋头就写程序，浑浑噩噩地进行开发然而很快我便发现，「事先设计」（upfront design）可 以助我节省回头工的高昂成本于是我很快加强這种「预先设计」风格。许多人都把设计看做软件开发的关键环节而把编程（programming）看做只是机械式的低级劳动。他们认为设计就像画工程圖而编码就像施工但是你要知道，软件和真实器械有着很大的差异软件的可塑性更强，而且完全是思想产品正如Alistair Cockburn所说：『有了设计，我可以思考更快但是其中充满小漏洞。』

有一种观点认为：重构可以成为「预先设计」的替代品这意思是你根本不必做任何设计，呮管按照最初想法开始编码让代码有效运作，然后再将它重构成型事实上这种办法真的可行。我的确看过有人这么做最后获得设