重构:改善既有代码的设计(中文版)(09年度畅销榜TOP50)(08年度畅销榜TOP50)
基本信息
- 作者: Martin Fowler [作译者介绍]
- 译者: 侯捷 熊节
- 丛书名: 软件工程系列
- 出版社:中国电力出版社
- ISBN:7508315545
- 上架时间:2003-7-31
- 出版日期:2003 年8月
- 开本:16开
- 页码:431
- 版次:1-1
- 所属分类:
计算机 > 软件工程及软件方法学 > 综合
编辑推荐
软件工程领域的超级经典巨著,与另一巨著《设计模式》并称"软工双雄",全美销量超过100000册,亚马逊书店五星书。
在本书中,作者Martin Fowler充分展示了何处可能需要重构,以及如何将不好的设计改造为良好的设计。
当对象技术成为老生常谈之后——尤其在Java编程语言之中,新的问题也在软件开发社区中浮现了出来。缺乏经验的开发人员完成了大量粗劣设计,获得的程序不但缺乏效率,也难以维护和扩展。渐渐地,软件系统专家发现,与这些沿袭下来的、质量不佳的程序共处,是多么艰难。对象专家运用许多技术来改善既有程序的结构完美性与性能,已有数年之久。
推荐阅读
内容简介回到顶部↑
书籍
计算机书籍
[b]侯捷2003年最新译作[/b] [a href="http://www.china-pub.com/computers/ebook10000-15000/12901/yangzhang.zip" target="_blank"]样章下载[/a]
软件工程领域的超级经典巨著,与另一巨著《设计模式》并称"软工双雄",[font color="#ff0000"]全美销量超过100000册[/font],亚马逊书店[font color="#ff0000"]五星书[/font]。
在本书中,作者martin fowler充分展示了何处可能需要重构,以及如何将不好的设计改造为良好的设计。
[a href="http://www.china-pub.com/computers/common/info.asp?id=12301" target="_blank"]查看影印版[/a]
计算机书籍
[b]侯捷2003年最新译作[/b] [a href="http://www.china-pub.com/computers/ebook10000-15000/12901/yangzhang.zip" target="_blank"]样章下载[/a]
软件工程领域的超级经典巨著,与另一巨著《设计模式》并称"软工双雄",[font color="#ff0000"]全美销量超过100000册[/font],亚马逊书店[font color="#ff0000"]五星书[/font]。
在本书中,作者martin fowler充分展示了何处可能需要重构,以及如何将不好的设计改造为良好的设计。
[a href="http://www.china-pub.com/computers/common/info.asp?id=12301" target="_blank"]查看影印版[/a]
作译者回到顶部↑
本书提供作译者介绍
Martin Fowler是一位独立咨询顾问,他运用对象技术解决企业问题已经超过十年。他的顾问领域包括健康管理、金
融贸易,以及法人财务。他的客户包括Chrysler,Citibank,UK National Health Service,AndersenConsulting,Netscape
Communications。此外Fowler也是objects、UML、patterns技术的一位合格讲师,,他是《AnalysisPatterns》和《UML
Distilled》的作者。
Kent Beck是一位知名的程序员、测试员、重构员、作家、五弦琴专家。
John Brant和Don Roberts是《Refactoring Browser .. << 查看详细
融贸易,以及法人财务。他的客户包括Chrysler,Citibank,UK National Health Service,AndersenConsulting,Netscape
Communications。此外Fowler也是objects、UML、patterns技术的一位合格讲师,,他是《AnalysisPatterns》和《UML
Distilled》的作者。
Kent Beck是一位知名的程序员、测试员、重构员、作家、五弦琴专家。
John Brant和Don Roberts是《Refactoring Browser .. << 查看详细
目录回到顶部↑
译序by侯捷 i
译序by熊节 v
序言(foreword)by erich gamma xiii
前言(preface)by martin fowler xv
什么是重构(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
译序by熊节 v
序言(foreword)by erich gamma xiii
前言(preface)by martin fowler xv
什么是重构(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
前言回到顶部↑
从前,有位咨询顾问参访一个开发项目。系统核心是个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 ─ 的时候,这份名录就会提醒我如何一步一步安全前进。我希望这是值得你日后一再回顾的部份。
这位顾问于是建议项目经理看看这些代码,把它们整理一下,但是经理并不热衷于此,毕竟程序看上去还可以运行,而且项目面临很大的进度压力。于是经理说,晚些时候再抽时间做这些整理工作。
顾问也把他的想法告诉了在这个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 ─ 的时候,这份名录就会提醒我如何一步一步安全前进。我希望这是值得你日后一再回顾的部份。
序言回到顶部↑
by Erich Gamma
重构(refactoring)这个概念来自Smalltalk圈子,没多久就进入了其它语言阵营之中。由于重构是framework(框架)开发中不可缺少的一部份,所以当framework开发人员讨论自己的工作时,这个术语就诞生了。当他们精炼自己的class hierarchies(类阶层体系)时,当他们叫喊自己可以拿掉多少多少行代码时,重构的概念慢慢浮出水面。framework设计者知道,这东西不可能一开始就完全正确,它将随着设计者的经验成长而进化;他们也知道,代码被阅读和被修改的次数远远多于它被编写的次数。保持代码易读、易修改的关键,就是重构 ─ 对framework而言如此,对一般软件也如此。
好极了,还有什么问题吗?很显然:重构具有风险。它必须修改运作中的程序,这可能引入一些幽微的错误。如果重构方式不恰当,可能毁掉你数天甚至数星期的成果。如果重构时不做好准备,不遵守规则,风险就更大。你挖掘自己的代码,很快发现了一些值得修改的地方,于是你挖得更深。挖得愈深,找到的重构机会就越多…于是你的修改也愈多。最后你给自己挖了个大坑,却爬不出去了。为了避免自掘坟墓,重构必须系统化进行。我在《Design Patterns》书中和另外三位(协同)作者曾经提过:design patterns(设计模式)为refactoring(重构)提供了目标。然而「确定目标」只是问题的一部份而已,改造程序以达目标,是另一个难题。
Martin Fowler和本书另几位作者清楚揭示了重构过程,他们为面向对象软件开发所做的贡献,难以衡量。本书解释重构的原理(principles)和最佳实践方式(best practices),并指出何时何地你应该开始挖掘你的代码以求改善。本书的核心是一份完整的重构名录(catalog of refactoring),其中每一项都介绍一种经过实证的代码变换手法(code transformation)的动机和技术。某些项目如Extract Method和Move Field看起来可能很浅显,但不要掉以轻心,因为理解这类技术正是有条不紊地进行重构的关键。本书所提的这些重构准则将帮助你一次一小步地修改你的代码,这就减少了过程中的风险。很快你就会把这些重构准则和其名称加入自己的开发词典中,并且朗朗上口。
我第一次体验有纪律的、一次一小步的重构,是在30000英呎高空和Kent Beck共同编写程序(译注:原文为pair-programming,应该指的是eXtreme Programming中的所谓「成对/搭档 编程」)。我们运用本书收录的重构准则,保证每次只走一步。最后,我对这种实践方式的效果感到十分惊讶。我不但对最后结果更有信心,而且开发压力也小了很多。所以,我高度推荐你试试这些重构准则,你和你的程序都将因此更美好。
─ Erich Gamma
Object Technology International, Inc.
重构(refactoring)这个概念来自Smalltalk圈子,没多久就进入了其它语言阵营之中。由于重构是framework(框架)开发中不可缺少的一部份,所以当framework开发人员讨论自己的工作时,这个术语就诞生了。当他们精炼自己的class hierarchies(类阶层体系)时,当他们叫喊自己可以拿掉多少多少行代码时,重构的概念慢慢浮出水面。framework设计者知道,这东西不可能一开始就完全正确,它将随着设计者的经验成长而进化;他们也知道,代码被阅读和被修改的次数远远多于它被编写的次数。保持代码易读、易修改的关键,就是重构 ─ 对framework而言如此,对一般软件也如此。
好极了,还有什么问题吗?很显然:重构具有风险。它必须修改运作中的程序,这可能引入一些幽微的错误。如果重构方式不恰当,可能毁掉你数天甚至数星期的成果。如果重构时不做好准备,不遵守规则,风险就更大。你挖掘自己的代码,很快发现了一些值得修改的地方,于是你挖得更深。挖得愈深,找到的重构机会就越多…于是你的修改也愈多。最后你给自己挖了个大坑,却爬不出去了。为了避免自掘坟墓,重构必须系统化进行。我在《Design Patterns》书中和另外三位(协同)作者曾经提过:design patterns(设计模式)为refactoring(重构)提供了目标。然而「确定目标」只是问题的一部份而已,改造程序以达目标,是另一个难题。
Martin Fowler和本书另几位作者清楚揭示了重构过程,他们为面向对象软件开发所做的贡献,难以衡量。本书解释重构的原理(principles)和最佳实践方式(best practices),并指出何时何地你应该开始挖掘你的代码以求改善。本书的核心是一份完整的重构名录(catalog of refactoring),其中每一项都介绍一种经过实证的代码变换手法(code transformation)的动机和技术。某些项目如Extract Method和Move Field看起来可能很浅显,但不要掉以轻心,因为理解这类技术正是有条不紊地进行重构的关键。本书所提的这些重构准则将帮助你一次一小步地修改你的代码,这就减少了过程中的风险。很快你就会把这些重构准则和其名称加入自己的开发词典中,并且朗朗上口。
我第一次体验有纪律的、一次一小步的重构,是在30000英呎高空和Kent Beck共同编写程序(译注:原文为pair-programming,应该指的是eXtreme Programming中的所谓「成对/搭档 编程」)。我们运用本书收录的重构准则,保证每次只走一步。最后,我对这种实践方式的效果感到十分惊讶。我不但对最后结果更有信心,而且开发压力也小了很多。所以,我高度推荐你试试这些重构准则,你和你的程序都将因此更美好。
─ Erich Gamma
Object Technology International, Inc.


点击看大图








加载中...


