VIP会员
内容简介
本书运用大量源于实践的示例，从编码、设计、组织、架构、测试、评估、应对需求变更等方面，深入而多角度地讲述了我们应该如何重构，建设性地提出了可行的重构七步。
读完本书，实践重构不再卡壳，需求变更不再纠结。全面领悟重构之美，遗留系统不再是梦魇，自动化测试原来可以这样做。
本书帮助程序员告别劣质代码步入精妙设计，让遗留系统的维护者逐步改善原有设计，指导重构实践者走出困惑步步坚定。同时，也为管理者加强软件质量的管理与监督，提供了好的方法与思路。
目录
第一部分 基础篇
第1章 重构：改变既有代码的一剂良药 2
1.1 什么是系统重构 2
1.2 在保险索上走钢丝 3
1.3 大布局与小步快跑 5
1.4 软件修改的四种动机 6
1.5 一个真实的谎言 9
第2章 重构方法工具箱 10
2.1 重构是一系列的等量变换——第一次HelloWorld重构 10
2.2 盘点我们的重构工具箱——对HelloWorld抽取类和接口 13
第3章 小步快跑的开发模式 19
3.1 大布局你伤不起 19
3.2 小设计而不是大布局 20
3.3 小步快跑是这样玩的——HelloWorld重构完成 22
第4章 保险索下的系统重构 30
4.1 你不能没有保险索 30
4.2 自动化测试——想说爱你不容易 31
4.3 我们是这样自动化测试的——JUnit下的HelloWorldTest 33
4.4 采用Mock技术完成测试 37
第二部分 实践篇
第5章 第一步：从分解大函数开始 44
5.1 大函数——软件退化的重灾区 44
5.2 抽取方法的实践 51
5.3 见的问题 54
第6章 第二步：拆分大对象 57
6.1 大对象的演化过程 57
6.2 大对象的拆分过程——抽取类与职责驱动设计 60
6.3 单一职责原则（SRP）与对象拆分 61
6.4 合久必分，分久必合——类的归并 63
第7章 第三步：提高代码复用率 66
7.1 顺序编程的烦恼 66
7.2 代码重复与DRY原则 67
7.3 提高代码复用的方法 69
7.3.1 当重复代码存在于同一对象中时——抽取方法 69
7.3.2 当重复代码存在于不同对象中时——抽取类 71
7.3.3 不同对象中复用代码的另一种方法——封装成实体类 72
7.3.4 当代码所在类具有某种并列关系时——抽取父类 75
7.3.5 当出现继承泛滥时——将继承转换为组合 76
7.3.6 当重复代码被割裂成碎片时——继承结合模板模式 78
7.4 代码重复的检查工具 79
第8章 第四步：发现程序可扩展点 80
8.1 开放?封闭原则与可扩展点设计 81
8.2 过程的扩展与放置钩子——运用模板模式增加可扩展点 85
8.3 面向切面的可扩展设计 89
8.4 其他可扩展设计 93
第9章 第五步：降低程序依赖度 98
9.1 接口、实现与工厂模式 98
9.1.1 理解工厂模式和依赖反转原则 98
9.1.2 工厂模式在重构中的实际运用 102
9.2 外部接口与适配器模式——与外部系统解耦 106
9.3 继承的泛滥与桥接模式 109
9.4 方法的解耦与策略模式 112
9.5 过程的解耦与命令模式 116
9.6 透明的功能扩展与设计——组合模式与装饰者模式 119
第10章 第六步：我们开始分层了 128
10.1 什么才是我们需要的分层 128
10.2 怎样才能拥抱需求的变化 131
10.3 贫血模型与充血模型 136
10.4 我们怎样面对技术的变革 139
第11章 一次完整的重构过程 143
11.1 第一步：分解大函数 143
11.2 第二步：拆分大对象 145
11.3 第三步：提高复用率 147
11.4 第四步：发现扩展点 148
11.5 第五步：降低依赖度 151
11.6 第六步：分层 151
11.7 第七步：领域驱动设计 153
第三部分 进阶篇
第12章 什么时候重构 156
12.1 重构是一种习惯 156
12.2 重构让程序可读 158
12.3 重构，才好复用 159
12.4 先重构，再扩展 161
12.5 变更任务紧急时，又该如何重构
摘要与插图
【前言】我常常感到幸运，我们现在所处的是一个令人振奋的时代，我们进入了软件工业时代。在这个时代里，我们进行软件开发已经不再是一个一个的小作坊，我们在进行着集团化的大规模开发。我们开发的软件不再是为某个车间、某个工序设计的辅助工具，它从某个单位走向整个集团，走向整个行业，甚至整个社会，发挥着越来越重要的作用。一套软件所起到的作用与影响有多大，已经远远超越了所有人的想象，成为一个地区、一个社会，乃至整个国家不可或缺的组成部分。慢慢地，人们已经难以想象没有某某软件或系统的生活和工作会是怎样的。这就是软件工业时代的重要特征。
然而，在这个令人振奋的软件工业时代，处于时代中心的各大软件企业却令人沮丧。在软件规模越来越庞大，软件结构越来越复杂的同时，却是软件质量越来越低下，软件维护变得越来越困难，以至于每个小小的变更都变得需要伤筋动骨。研发人员为此手足无措，测试人员成为的救星，每个小小的变更都需要付出巨大代价进行测试。软件企业在这样一种恶性循环中苦苦支撑。毫无疑问，这也成为这个令人振奋的时代的另一个特征。
是的，面对软件工业时代我们并没有做好准备。过去，一套软件的生命周期不过2~3年时间，随着软件需求的变化，我们总是选择将软件推倒了重新开发，但是现在这样的情况在发生着改变。随着软件规模的扩大，软件数据的积累，软件影响力的提升，我们，以及我们的客户，都真切地感受到，要推倒一套软件重新开发，将变得越来越困难且不切实际。这样的结果就是，我们的软件将不停地修改、维护、再修改、再维护……直到永远。这是一件多么痛苦的事情！
一套软件，当它第一次被开发出来的时候，一切都十分清晰：清晰的业务需求、清晰的设计思路、清晰的程序代码。但经历了几次需求变更与维护以后，一切就变得不那么清晰了。业务需求文档变得模糊不清，设计思路已经跟不上变更的脚步，程序代码则随着业务逻辑的复杂而臃肿不堪。程序员开始读不懂代码，软件开发工作变得不再是一种乐趣。
随着时间的推移，软件经过数年、数十次的变更与维护，情况变得越来越糟。的程序员已经不愿再看到自己的代码而选择离去。他的继任者们变得更加无所适从，由于看不懂程序，代码的每一次修改如同在走钢丝。测试人员变成了的希望，开发人员的每一次修改都意味着测试人员需要把所有程序测试一遍。继任者们开始质问的设计者们，程序是怎么设计的。如果此时恰巧又有什么新技术出现，就会更显得原有系统的破旧与不堪。
相信这就是软件工业时代的所有企业都不得不面对的尴尬境地。难道真的是我们的设计错了吗？是的，我们都这样质问过我们自己，因此我们开始尝试在软件设计之初投入更多的精力。我们开始投入更多的时间作需求调研，考虑更多可能的需求变化，做更多的接口，实现更加灵活但复杂的设计。然后呢，解决了我们的问题了吗？显然是没有。需求并没有像我们想象的那样发生变更：我们之前认为可能发生的变更并没有发生，使我们为之做出的设计变成了摆设；我们之前没有考虑到的变更却发生了，让我们猝不及防，软件质量开始下降，我们被打回了原形。难道真的是无药可解了吗？在我看来，如果我们没有看明白软件开发的规律与特点，那么我们永远找不到那味向往已久的解药。现在，让我们真正静下心来分析分析软件开发的规律与特点。
软件，是管理软件，其实质是对真实世界的模拟。我们通过对真实世界的模拟，实现计算机的信息化管理，来提高我们的生产效率。然而，真实的世界复杂而多变的，我们认识世界却是一个由简单到复杂循序渐进的过程，这是一个我们无法改变的客观规律。因此，毫无