大话重构连载首页

《大话重构》这本书是我写的第一本书,从今天起我将通过连载的形式逐渐跟大家分享。

这本书让你:

告别游击队转变为正规军。

远离劣质代码走向精妙设计

真正明确专业级的软件开发是如何的

真正明确重构是如何一步一步进行的

高效重构七步曲。面对实践不卡壳

让遗留系统维护不再是你的梦魇

读完这本书以后:

需求变更不再纠结。重构让你润物细无声地容纳它们

超越代码级的重构,从各个层面深度领略重构之美

自己主动化測试不再是梦想。重构让自己主动化測试走你

又一次审视熟悉而陌生的技术。将碎了一地的它们又一次铆合在一起

本书的文件夹:

遗留系统——软件工业时代的痛

第一部分 基础篇

重构,一个既熟悉又陌生的名词。

在这里,我首先给你诠释一个全然不同的重构,让你又一次理解一个最熟悉的陌生技术:

第1章 重构:改变既有代码的一剂良药

1.1 什么是系统重构

1.2 在保险索上走钢丝

1.3 大布局与小步快跑

1.4 软件改动的四种动机

1.5 一个真实的谎言

第2章 重构方法工具箱

2.1 重构是一系列的等量变换——第一次HelloWorld重构

2.2 盘点我们的重构工具箱——对HelloWorld抽取类和接口

第3章 小步快跑的开发模式

3.1 大布局你伤不起

3.2 小设计而不是大布局

3.3 小步快跑是这样玩的——HelloWorld重构完毕

第4章 保险索下的系统重构

4.1 你不能没有保险索

4.2 自己主动化測试——想说爱你不easy

4.3 我们是这样自己主动化測试的——JUnit下的HelloWorldTest

4.4 採用Mock技术完毕測试

第二部分 实践篇

当你充满激情地准备实践重构时,却发现自己在迈出第一步就卡壳了,有木有?高效可行的重构七步。让你面对实践不卡壳:

第5章 第一步:从分解大函数開始

5.1 超级大函数——软件退化的重灾区

5.2 抽取方法的实践

5.3 最常见的问题

第6章 第二步:拆分大对象

6.1 大对象的演化过程

6.2 大对象的拆分过程——抽取类与职责驱动设计 49

6.3 SRP原则与对象拆分 50

6.4 合久必分,分久必合——类的归并 52

第7章 第三步:提高代码复用率 54

7.1 顺序编程的烦恼 54

7.2 代码反复与DRY原则 55

7.3 提高代码复用的方法 56

7.3.1 当反复代码存在于同一对象中时——抽取方法

7.3.2 当反复代码存在于不同对象中时——抽取类

7.3.3 不同对象中复用代码的还有一种方法——封装成实体类

7.3.4 当代码所在的类具有某种并列关系时——抽取父类

7.3.5 当出现继承泛滥时——将继承转换为组合

7.3.6 当反复代码被割裂成碎片时——继承结合模板模式

7.4 代码反复的检查工具 64

第8章 第四步:发现程序可扩展点 64

8.1 开放-封闭原则(OCP)与可扩展点设计 65

8.2 过程的扩展与放置钩子——运用模板模式添加可扩展点 68

8.3 面向切面的可扩展设计 71

8.4 其他可扩展设计 74

第9章 第五步:减少程序依赖度 78

9.1 接口、实现与工厂模式 79

9.1.1 彻底理解工厂模式和依赖反转原则

9.1.2 工厂模式在重构中的实际运用

9.2 外部接口与适配器模式——与外部系统解耦 84

9.3 继承的泛滥与桥接模式 87

9.4 方法的解耦与策略模式 90

9.5 过程的解耦与命令模式 93

9.6 透明的功能扩展与设计——组合模式与装饰者模式 95

第10章 第六步:我们開始分层了 102

10.1 什么才是我们须要的分层 102

10.2 如何才干拥抱需求的变化 104

10.3 贫血模型与充血模型 108

10.4 我们如何面对技术的变革 111

第11章 一次完整的重构过程 113

11.1 第一步:分解大函数 113

11.2 第二步:拆分大对象 115

11.3 第三步:提高复用率 116

11.4 第四步:发现扩展点 117

11.5 第五步:减少依赖度 119

11.6 第六步:分层 120

11.7 第七步:领域驱动设计 121

第三部分 进阶篇 123

我已经是一个重构的实践者了,但重构真的让我想说爱你不easy,太多太多的难题让我困惑让我烦恼。

这里,让一个重构多年的实践者给你解惑吧:

第12章 什么时候重构 123

12.1 重构是一种习惯 123

12.2 重构让程序可读 125

12.3 重构,才好复用 126

12.4 先重构。再扩展 127

12.5 变更任务紧急时,又该怎样重构 129

第13章 測试驱动开发 131

13.1 測试驱动开发(TDD) vs. 后測试开发(TAD) 131

13.2 測试驱动开发与重构 134

13.3 遗留系统如何开展TDD 142

第14章 全面的升级任务 144

14.1 计划式设计VS演进式设计 144

14.2 风险驱动设计 146

14.3 制定系统重构计划 148

第15章 我们如何拥抱变化 149

15.1 领域才是软件系统的“心”——工资软件的三次设计演变 149

15.2 领域模型分析方法 155

15.3 原文分析法 157

15.4 领域驱动设计——使用领域模型与客户一起设计 160

15.5 在遗留系统中的应用 164

第16章 測试的困境 166

16.1 重构初期的困局 167

16.2 解耦与自己主动化測试 168

16.3 谁来写自己主动化測试程序? 171

16.4 建立自己主动化測试体系 174

第17章 系统重构的评价 175

17.1 评价软件质量的指标 175

17.2 如何评价软件质量呢 178

结束语:重构改变了世界 181

附录:重构方法速查手冊 182

时间: 2024-10-22 12:07:06

大话重构连载首页的相关文章

大话重构连载8:盘点我们的重构工具箱

下面我们来盘点一下系统重构工具箱里都有什么,也就是看一看系统重构到底都有哪些方法.系统重构总是在不同层次上调整我们的代码,因此重构方法也就分为了多个层次.从总体上看,重构方法分为以下几个层次:方法的重构.对象的重构.对象间的重构.继承体系间的重构.组织数据的重构与体系架构的重构. 前面那个例子我们可以清楚地看到方法的重构过程.方法的重构往往发生在一个对象的内部,是对一个对象内部的优化.从这个例子中,我们首先看到了增加注释.调整顺序.重命名变量.进行分段等操作,这些虽然不是什么重构方法,却是我们进

大话重构连载16:超级大函数

事情总是这样的:当我们对一个遗留系统一忍再忍,再忍,忍,还要忍--终于积攒到某一天,实在忍无可忍了,拍案而起,不能再忍了,重构!!!事情就这样发生了.然而,在这时你突然发现,重构的工作千头万绪,真不知从何开始.堆积如山的问题此起彼伏,期望修改的设计思绪万千.这里有个想法,那里有个思路,什么都想做,却什么都做不了,真是脑子里一团乱麻.这时候,没有一个合理的步骤,清晰的计划,瞎干蛮干是十分危险的,它会为你的重构带来不可预期的未来.无数次的经验告诉我,不论是什么系统,采用什么架构,从分解大函数开始,肯

大话重构连载12:你不能没有保险索

通过前面的描述你已经对重构中"小步快跑"的开发模式有了一个清楚的认识.学会和习惯小步快跑的开发模式,对于重构工作极其重要,因为它让这种大范围.大幅度修改代码的重构工作变得不再像以往那样让人胆战心惊.究其原因,虽然从结果上是在大范围.大幅度调整,但每一步却是小范围.小福度调整,并且能保证每一步都是正确的. 然而,这里有一个非常重要的假设条件,那就是"保证每一步都是正确的",这是怎么保证的呢?就这个问题,我们需要展开来认真讨论讨论. 毫无疑问,系统重构就其结果来看,是在

大话重构连载7:重构是一系列的等量变换

系统重构要求我们对代码的每一步修改,都不能改变软件的外部行为,因此在系统重构中的所有方法,都是一种代码的等量变换.重构的过程,就好像在做数学题,一步一步地进行算式的等量变换.经过一系列等量变换,最终的结果虽然在形式上与原式不一样,但通过计算可以得到与原式完全相同的结果. 这种等量变换对于重构来说非常重要,它使得我们进行重构以后,程序还是那些程序,代码还是那些代码.但是,等量变换不等于原地踏步.正如矩阵通过等量变换可以得到方程组的解,微积分可以通过等量变换计算最终的结果,重构通过等量变换,在保证代

大话重构连载4:大布局与小步快跑

以往我们在重新设计一个系统时,总是喜欢大布局.全面地整理系统需求,全面地分析系统功能,再全面地设计系统.开发.测试.这样一个过程往往会持续数月,花费大量的工作量.但是,不到最后设计出来,谁都不知道会不会存在问题.这就是“大布局”的弊病. 正因为如此,软件大师在讲述系统重构时总是强调,系统重构应当避免大设计,而应当尽量采用一个一个连续不断的小设计.这就是我们所说的“小步快跑”的设计模式. 小步快跑体现出了敏捷软件开发的特点——简单与快速反馈.不要想得太多了,活在今天的格子里,因为你永远不可能预知今

大话重构连载2:什么是系统重构

当我们开始系统重构的时候,不是着手去修改代码,而是首先建立测试机制.不论什么程序,只要是被我们修改了,理论上就可能引入BUG,因此我们就必须要进行测试.既然是测试就必须要有一个正确与否的评判标准.以往的测试,其评判的标准就是是否满足业务需求.因此,测试人员往往总是拿着需求文档测试系统. 与以往的代码修改不同,重构没有引入任何新的需求,系统原来什么功能,重构以后还是这些功能.因此,重构的测试标准就只有一个,就是与之前的功能完全保持一致,仅此而已. 然而在许多经典的重构书籍中,大师们总是建议我们首先

大话重构连载1:遗留系统——软件工业时代的痛

我常常感到幸运,我们现在所处的是一个令人振奋的时代,我们进入了软件工业时代.在这个时代里,我们进行软件开发已经不再是一个一个的小作坊,我们在进行着集团化的大规模开发.我们开发的软件不再是为某个车间.某个工序设计的辅助工具,它从某个单位走向整个集团,走向整个行业,甚至整个社会,发挥着越来越重要的作用.一套软件所起到的作用与影响有多大,已经远远超越了所有人的想象,成为一个地区.一个社会,乃至整个国家不可或缺的组成部分.慢慢地,人们已经难以想象没有某某软件或系统的生活和工作会是怎样的.这就是软件工业时

大话重构连载:遗留系统——软件工业时代的痛

我经常感到幸运,我们如今所处的是一个令人振奋的时代,我们进入了软件工业时代.在这个时代里,我们进行软件开发已经不再是一个一个的小作坊,我们在进行着集团化的大规模开发.我们开发的软件不再是为某个车间.某个工序设计的辅助工具.它从某个单位走向整个集团,走向整个行业,甚至整个社会,发挥着越来越关键的数据.一套软件所起到的作用与影响有多大.已经远远超越了全部人的想象.成为一个地区.一个社会.乃至整个国家不可或缺的组成部分. 慢慢地,人们已经难以想象没有某某软件或系统的生活和工作会是如何的.这就是软件工业

大话重构连载18:最常见的问题

使用抽取方法,虽然道理十分简单,但实际操作起来却并不是那么容易的.完成抽取方法最大的困难,就是如何处理抽取函数与原函数的数据交换.如同将一颗大树从土壤里拔出来,盘根错节的根茎,那是剪不断理还乱.当代码还没有被抽取出来之前,它们与其它程序都是在一个函数的内部,因此各个代码段可以毫无顾忌地相互交互数据.但当我们将代码从原函数中抽取出来时,抽取出来的代码与原函数中的代码就形成了一道墙,要交换的数据只能通过参数与返回值进行交互,这将给我们带来诸多麻烦. 将代码从原函数中抽取出来,放进新的函数中,首先就会