超级会员免费看
《重构》是一本关于改善代码设计的书籍，强调在不改变代码外在行为的前提下改进程序内部结构。重构有助于提高代码可读性和降低修改成本，通过一系列微小步骤进行，确保每一步都有可靠的测试保障。书中介绍了重构的原则，如何时重构、为何重构，并提供了重构名录。重构挑战包括可能影响新功能开发、代码所有权、测试等问题，但自动化重构和良好的测试集能降低风险。通过构筑测试体系，重构可以与软件开发过程紧密结合，提高整体开发效率。
目录
重构十六字心法：
旧的不变，
新的创建，
一步切换，
旧的再见。
什么是重构
所谓重构（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、挑选重构的依据
https://blog.csdn.net/wohiusdashi
扫一扫
372
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
