重构:改善既有代码的设计(一)

《重构》是一本关于改善代码设计的书籍,强调在不改变代码外在行为的前提下改进程序内部结构。重构有助于提高代码可读性和降低修改成本,通过一系列微小步骤进行,确保每一步都有可靠的测试保障。书中介绍了重构的原则,如何时重构、为何重构,并提供了重构名录。重构挑战包括可能影响新功能开发、代码所有权、测试等问题,但自动化重构和良好的测试集能降低风险。通过构筑测试体系,重构可以与软件开发过程紧密结合,提高整体开发效率。
摘要由CSDN通过智能技术生成

目录

重构十六字心法:

什么是重构

前言:对本书的赞誉

第一章、重构、第一个示例

第二章、重构的原则

1、何谓重构

2、二顶帽子

3、为何重构?

4、何时重构?

5、重构的挑战

6、重构、架构和YAGNI

7、重构与软件开发过程

8、重构与性能

9、重构起源何处

10、自动化重构

第三章、代码的坏味道

第四章、构筑测试体系

第五章、介绍重构名录


重构十六字心法:

旧的不变,

新的创建,

一步切换,

旧的再见。

什么是重构

所谓重构(refactoring)是这样一个过程:在不改变代码外在行为的前提下,对代码做出修改,以改进程序的内部结构。重构是一种经千锤百炼形成的有条不紊的程序整理方法,可以最大限度地减小整理过程中引入错误的概率。本质上说,重构就是在代码写好之后改进它的设计。

重构有风险:它必须修改正在工作的程序,这可能引入一些不易察觉的错误。如果重构方式不恰当,可能毁掉你数天甚至数周的成果。如果重构时不做好准备,不遵守规则,风险就更大。你挖掘自己的代码,很快发现了一些值得修改的地方,于是你挖得更深。挖得越深,找到的重构机会就越多,于是你的修改也越多……最后你给自己挖了个大坑,却爬不出去了。为了避免自掘坟墓,重构必须系统化进行

前言:对本书的赞誉

过去 20 年, 《重构》一直是我案头常备的图书。每次重读,仍有感悟。对我而言,

《重构》的意义不只在于指导代码重构,更在于让人从一开始就知道什么是好的代码,

并且尽量写出没有“坏味道”的代码。Martin Fowler 这次对本书进行的重构,体现了

近年来编程领域的一些思潮变化。看来,既有设计,永远有改进空间。

——韩磊,《代码整洁之道》译者

重构早就成了软件开发从业者本能的一部分,每个 IDE 都内置了重构功能,每

个程序员都定期重构自己的代码。技能上通常不再是问题,但是相对于当年第 1 版的

读者,现在的程序员对于重构这个思想从何而来以及各种细节反而更陌生,这时候就

更值得重新读一下这本书了。

——霍炬,PRESS.one CTO

有人说 Martin Fowler 改变了人类开发软件的模式,这一点也不过分,从《分析

模式》《UML 精粹》《领域特定语言》,到这本《重构》新版可以看得出来,他的每一

本书都是软件开发人员必备的案头读物。此前他参与的“敏捷宣言”,更是引领了整

个行业对敏捷开发的认识,一直到现在。Martin Fowler 是我们 QCon 全球软件开发大

会进入中国时的第一届讲师,也是在那次会议上,他让国内的技术社区领略了国际领

先的开发模式,从此“敏捷”二字开始风行国内 IT 领域。

今年是 QCon 进入中国的第十个年头,我特别开心看到 Martin Fowler 又重写《重

构》这本影响深远的书,他几乎完全替换了书中所引用的模式案例,并且基于现在用

户的习惯,采用了 JavaScript 语言来做说明语言。数十年来他始终保持对技术的关注,

对创新的热情,乐此不疲,这是 Martin 最令人敬佩的地方,也是非常值得我们每一

个技术人学习的地方。

——霍泰稳,极客邦科技、InfoQ 中国创始人兼 CEO

网站系统开发中充分认识到重构的重要性——如果我们的程序员能理解和掌握重构的

原则和方法,我们的系统就不会有这么多沉重的债务。真正本质的东西是不变的, 《重

构》在出版 20 年后推出了第 2 版,再次证明:越本质的越长久,也越重要。衷心期

待更多的新一代开发者能从这本书吸收营养,开发出好味道的系统。

——蒋涛,CSDN 创始人、董事长

最早看到本书第 1 版的英文原版并决定引进国内,算起来已经是 20 年前的事了。

虽然时间是最强大的重构工具,连书里的示例语言都从 Java 变成 JavaScript 了,但书

中的理念和实践的价值并没有随时间流逝。这充分证明,即使在日新月异的 IT 技术

世界里,不变的东西其实还是有的,这种书才是真正的经典,是技术人员应该优先研

读并一读再读的。

——刘江,美团技术学院院长

“对于软件工程师来说,重构,并不是额外的工作,它就是编码本身。”直到我

读过《重构》,并经过练习,才真正理解到这一点。真希望自己在 20 多年前写第一

个软件时,就能读到这本书,从而能节省出大量调试或重复研究代码的时间。20 年

过去了,《重构》这本书也根据当前软件设计及相关工具的发展进行了一部分修订,

更加贴近当前的软件开发者。希望更多的软件工程师能够应用这一技术节省出更多

的时间。

——乔梁,腾讯高级管理顾问、《持续交付 2.0》作者

重构是一项被低估了的技术能力。说起来,重构就是“不改变外在行为,而提高

代码质量”这么简简单单的一句话,但其带来的影响却非常深远:它使我们在解决问

题时可以放心地“先做对,再做好”——这种思路本身就可以极大地简化问题;它使

我们消除无谓的意气之争——“所谓好,就是更少的坏味道”。我由衷地认为,切实

地读懂了《重构》的程序员,在能力上都会获得一个数量级的提升。

——徐昊,ThoughtWorks 中国区技术总监

当我还是编程菜鸟,想写出漂亮的代码而不得门道的时候,《重构》这本书就告

诉了我,其实高手的代码也不是一次书就的,只要按这本书里的方法去做,谁都能把

代码写得那么好;当我还是职场新人,没来得及写出太多垃圾代码的时候,这本书就

教会了我,应该去追求编写人能够读懂的而不是仅机器能够读懂的代码。多年以后的

某时某刻,当你编码自信而敏捷,因代码清晰而受人尊重时,你会庆幸读过这本书,

你也会有些遗憾,应该再早一点去读这本书。无论过去了多少年,这本书,一直值得

推荐。

——阎华,京东 7FRESH 架构师

在大获成功的《重构》第 1 版里,Martin Fowler 传达的核心理念是:代码会随时

间流逝而烂掉。写得再好的程序代码,若是发布了就一直保持原样,照样会风化、破

碎乃至分崩离析。这是客观规律,避免这种命运的唯一出路是持续重构。要想成为高

素质的软件工程师,必须认识这一点。

20 年之后,Martin Fowler 用现身说法证明,经典的《重构》也会变得不合时宜,

也需要重构。如今,不但讲解语言从 Java 改成了 JavaScript,原来的重构示例也做了

很多调整,新增了 15 个示例,更重要的是,新版示例不再那么“面向对象”,应当会

收获更广泛的读者群。

软件不死,重构不歇。

——余晟,《代码整洁之道:程序员的职业素养》译者

随着软件项目日积月累,系统维护成本变得越来越高昂是互联网团队共同面临的

问题。用户在使用互联网系统的过程中,遇到的各类运行错误或者不可访问故障,以

及开发团队面临的历史系统不可维护问题,很多时候是代码初次开发过程中各种细小

的不规范引起的。持续优化已有代码是维护系统生命力最好的方法。《重构》是我推

荐团队必读的技术图书之一。

——杨卫华(Tim Yang),微博研发副总经理

软件行业已经高速发展数十年,就好似一个崭新的城市,从一个个村屋矮房到高

楼林立。而你的代码库就好比你手下的一个房间、一幢平房、一条街道、一片社区乃

至是一座摩天大楼。作为一本经典的软件开发书籍,《重构》告诉我们的不仅仅是如

何推倒重建、清理、装修,而是像一个规划师一样从目的、成本、手段、价值等综合

维度来思考重构的意义。在开发业务的同时,《重构》常伴我左右,警醒我如何写出

更有价值的软件。

——阴明,掘金社区创始人

重构,是一个优秀程序员的基本功,因为没人能保证其代码不随时间腐化,而重

构会让代码重新焕发活力。整个软件行业对重构的认知始于 Martin Fowler 的《重构》,

这本书让人们知道了“代码的坏味道”,见识到了“小步前行”的威力。时隔 20 年,

Martin Fowler 重新执笔改写《重构》,20 年间的思维变迁就体现在这本书里,在第 1

版中,我们看到的是当时方兴未艾的面向对象,而第 2 版则透露出函数式编程的影

响。如果说有什么程序员进阶秘笈,那就是不要错过 Martin Fowler 的任何一部著作,

更何况是已经由时间证明过的重要著作《重构》的新版!

——郑晔,火币网首席架构师

如果看完本书,就兴冲冲地想要找一些代码来重构,那你可能就陷入某种“自

嗨”之中了。

了解本书中列出的那些坏味道,不仅仅可以发现代码中的那些坏味道,更可以鞭

策自己以及整个团队:在一开始的时候,就不写或者少些那种味道很坏的代码。还应

该激励自己,深入地理解架构、理解业务、理解需求,减少因设计失误而导致徒劳无

益地反复重构。

重构也是有成本的,所以应该思考如何降低重构的成本。我推荐每一个程序员都

来学习“重构”这门手艺。因为学习《重构》,是为了减少“重构”!

——庄表伟,开源社理事、执行长,华为云 DevCloud 高级产品经理

第一章、重构、第一个示例

如果你要给程序添加一个特性,但发现代码因缺乏良好的结构而不易于进行更改,那就先重构那

个程序,使其比较容易添加该特性,然后再添加该特性。

1、重构第一步

1.1、重构前,先检查自己是否有一套可靠的测试集。这些测试必须有自我检验能力。

1.2、重构技术就是以微小的步伐修改程序。如果你犯下错误,很容易便可发现它。

1.3、傻瓜能写出计算机可以理解的代码。唯有能写出人类容易理解的代码的,才是优秀的程序员

1.4、尽管将函数变量改变成函数声明也是一种重构手法,但我既未为此手法命名,也未将它纳入

重构名录。还有很多的重构手法我都觉得没那么重要。我觉得上面这个函数改名的手法既十

分简单又不太常用,不值得在重构名录中占有一席之地。

1.5、编程时,需要遵循营地法则:保证你离开时的代码库一定比来时更健康。

1.6、好代码的检验标准就是人们是否能轻而易举地修改它。

1.7、良好的设计必须在开始编程之前完成,因为一旦开始编写代码,设计就只会逐渐腐败。

第二章、重构的原则

1、何谓重构

1.1、重构(名词):对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提

高其可理解性,降低其修改成本。

1.2、重构(动词):使用一系列重构手法,在不改变软件可观察行为的前提下,调整其结构。

1.3、如果有人说他们的代码在重构过程中有一两天时间不可用,基本上可以确定,他们在做的事

不是重构。

2、二顶帽子

添加新功能和重构。

3、为何重构?

3.1、重构改进软件的设计

3.2、重构使软件更容易理解

3.3、重构帮助找到bug

3.4、重构提高编程速度

3.5、让添加新功能更容易

3.6、使代码更易懂

4、何时重构?

4.1、三次法则:事不过三,三则重构。

4.2、每次修改时,首先令修改很容易(警告:这件事有时会很难),然后再进行这次容易的修改

4.3、捡垃圾式重构(发现不好的代码就改)

4.4、有计划的重构和见机行事的重构

肮脏的代码必须重构,但漂亮的代码也需要很多重构。

4.5、长期重构

4.6、复审代码(Code View 代码检查)时重构

何时不应该重构?

如果重写比重构还容易,就别重构了

5、重构的挑战

5.1、延缓新功能开发

重构的唯一目的就是让我们开发更快,用更少的工作量创造更大的价值。

5.2、代码所有权

很多重构手法不仅会影响一个模块内部,还会影响该模块与系统其他部分的关系

5.3、分支

一般master为主干分支是稳定的生产环境分支,一般在dev上分支进行开发,那么带来的问

题就是,隔离的时间越久,工作分支的合并越困难。

5.4、测试

重构风险太大,可能引入bug

5.5、遗留代码

重构可以很好地帮助我们理解遗留系统

5.6、数据库

借助数据迁移脚本,将数据库结构的修改与代码相结合,使大规模的、涉及数据库的修改

可以比较容易地开展。

6、重构、架构和YAGNI

软件设计的方法、简单设计、增量设计及YAGNI,你不需要它,You arent not going need it

的缩写,被视为架构、设计、与开发过程整合的一种工作方式,它必须有重构作为基础才可靠。

7、重构与软件开发过程

自测试代码,持续集成,重构,它们彼此之间有着很强的协同效应。

8、重构与性能

先写出可调优的软件,再调优它 以求获得足够的速度。

80%的性能问题出在20%的代码上。遵循2-8原则。

9、重构起源何处

我曾想找出重构的起源,最终失败了,优秀的程序员至少会花些时间来清理自己的代码。

10、自动化重构

工具完成的重构是可靠的,所以用不着运行测试套件。

第三章、代码的坏味道

1、神秘命名(Mysterious Name)

2、重复代码(Duplicated Code)

3、过长函数(Long Method)

4、过长参数列表(Long Parameter List)

5、全局数据(Global Data)

6、可变参数(Mutable Data)

7、发散式变化(Divergent Change):容易被修改

8、霰弹式修改(Shotgun Surgery):每变化时都需要在许多类中做修改。

9、依恋情绪(Feature Envy):一个函数与其它模块交流过于频繁。

10、数据泥团(Data Clumps):二个以上类出现相同字段。

11、基本类型偏执(Primitive Obsession):将一组基本类型变量替换成对象。

12、重复的Switch(Repeated Switches)

所有条件逻辑都应该用多态,绝大多数的if语句补扫进历史的垃圾桶。

13、循环语句(Loops)

14、冗赘的元素(Lazy Element):不要写功能相同的代码

15、夸夸其谈通用性(Speculative Generality):不要添加一些可能将来会用到但现在没有使用代码

16、临时字段(Temporary Field):一个类的某个字段是为某种特定情况而设。

17、过长的消息链(Message Chains)

一个请求内部之间存在多个请求的调用,带的缺点是出现问题时不好排查。

18、中间人(Middle Man)

一个对象与另一个对象进行交互时通过中间人(代理)进行,带来的问题是不效率变低和不好排

查问题

19、内幕交易(Inside Trading)

二个模块之间大量交换数据,会增加模块间的耦合。应该把它们抽离出来。

20、过大的类(Large Class)

如果一个类过大,必然会造成很多重复的字段和方法。

21、异曲同工的类(Alternative Classes With Different Interface)

尽量使用接口,因为接口的替换性较高,易扩展。

22、纯数据类(Data Class)

此只拥有一些属性和相应的get/set方法,没有任何其它方法。

23、被拒绝的遗赠(Refused Bequest)

父类的一些属性或方法在子类中根本没用到或子类需要重写父类的方法来实现自己的业务。

24、注释(Comments)

当你感觉需要写注释时,请先尝试重构,试着让所有注释变得多余。

第四章、构筑测试体系

1、自测试代码的价值

1.1、编写代码只花费一小部分时间,大多数时间花费在设计和调试上。

1.2、类应该包含它的自澧代码。

1.3、确保所有测试都完全自动化,让它们检查自己的测试结果。

1.4、一套测试就是一个强大的BUG侦测器,能够大大缩减查找BUG所需要的时间。

1.5、一旦测试代码正常运行,工作就可以结束了。

1.6、不要因为测试无法捕捉所有的bug就不写测试,因为测试的确可以捕捉到大多数bug。

2、待测试的示例代码

3、第一个测试

4、再添加一个测试

5、修改测试夹具

6、探测边界条件

考虑可能出错的边界条件,把测试火力集中在那儿。

7、测试远不止如此

每当你收到bug报告,请先写一个单元测试来暴露这个bug。

第五章、介绍重构名录

1、重构的记录格式

1.1、重构手法

名称(Name):重构的名称。

速写(Sketch):可以帮助你更快找到所需要的重构手法 。

动机(Motivation):为什么重构?什么情况下不应该重构?

做法(Mechanical):如何进行重构?

范例(Example):以一个十分简单的例子说明此重构手法如何运作。

2、挑选重构的依据

更多精彩技术分享请浏览本人博客:不甘于平凡的溃败的博客_CSDN博客-java,数据库,IDEA领域博主不甘于平凡的溃败擅长java,数据库,IDEA,等方面的知识,不甘于平凡的溃败关注spring,spring boot,python,架构,java,elasticsearch,linux,mysql,分布式,redis领域.https://blog.csdn.net/wohiusdashi

第1章 重构,第一个案例 1 1.1 起点 1 1.2 重构的第一步 7 1.3 分解并重组statement() 8 1.4 运用多态取代与价格相关的条件逻辑 34 1.5 结语 52 第2章 重构原则 53 2.1 何谓重构 53 2.2 为何重构 55 2.3 何时重构 57 2.4 怎么对经理说 60 2.5 重构的难题 62 2.6 重构设计 66 2.7 重构与性能 69 2.8 重构起源何处 71 第3章 代码的坏味道 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 Shotgun 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 InheritanceHierarchies(平行继承体系) 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章 构筑测试体系 89 4.1 自测试代码的价值 89 4.2 JUnit测试框架 91 4.3 添加更多测试 97 第5章 重构列表 103 5.1 重构的记录格式 103 5.2 寻找引用点 105 5.3 这些重构手法有多成熟 106 第6章 重新组织函数 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章 在对象之间搬移特性 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章 重新组织数据 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(以State/Strategy取代类型码) 227 8.16 Replace Subclass with Fields(以字段取代子类) 232 第9章 简化条件表达式 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章 简化函数调用 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 Methods(以函数取代参数) 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章 处理概括关系 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 Tem Plate Method(塑造模板函数) 345 11.11 Replace Inheritance with Delegation(以委托取代继承) 352 11.12 Replace Delegation with Inheritance(以继承取代委托) 355 第12章 大型重构 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 13.1 现实的检验 380 13.2 为什么开发者不愿意重构他们的程序 381 13.3 再论现实的检验 394 13.4 重构的资源和参考资料 394 13.5 从重构联想到软件复用和技术传播 395 13.6 小结 397 13.7 参考文献 397 第14章 重构工具 401 14.1 使用工具进行重构 401 14.2 重构工具的技术标准 403 14.3 重构工具的实用标准 405 14.4 小结 407 第15章 总结 409
一直很喜欢重构这本书,但是由于自己记性不太好,书看过之后其中的方法总是记不住,于是想如果有电子版的重构书就好了,工作中遇到重构的问题可以随时打开查阅。在网上搜索了许久,发现重构这本书有英文chm版本的,而中文版的电子书只有扫描的PDF版本,用起来非常不方便。于是萌生想做一本重构工具书的想法,本来打算自己重新将重构书的内容再整理归类一下,后来发现原书的目录编排就很适合做工具书,包括坏味道分类,重构手法归类等,都有了一个比较系统的整理。因此,我利用空余时间制作了这样的一本中文的chm版重构,希望对大家有所帮助,也算对中国软件业做出一点小小的贡献。 本书基本上是取自”重构”中文版一书的内容,但格式上参照的是chm英文版的格式,还有一些格式小修改,比如第一章的重构前后代码对比。因为时间匆促,个人能力有限,本书难免存在一些缺漏,如果大家发现有问题,随时可以给我发邮件,我会尽快更新错误的内容。 最后再次感谢几位大师 Martin Fowler、Kent Beck等,还有翻译的侯捷和熊节先生,为我们带来这么精彩的一本书。谢谢。 免责声明:本书仅供个人学习研究之用,不得用于任何商业目的,不得以任何方式修改本作品,基于此产生的法律责任本人不承担任何连带责任。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

不甘于平凡的溃败

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值