大话重构pdf

图书网 2018年8月23日12:11:491 2.4K
摘要

《大话重构》第一部分用大量的篇幅分析了瀑布流程的问题,并阐述了迭代增量式的经验型软件开发方法能够解决复杂项目中的问题。如果你是管理者,因为在软件开发中碰到的问题而感到纠结和困扰,想尝试其他办法,那么本书系统介绍的敏捷思维会打开你的思路。第二部分介绍了如何渐进式地向Scrum转型,并分析了一些案例。
书中会介绍如何利用一套流程来创造商业价值,这套流程能保证至少每30天就交付完整的软件功能模块;如何对你所需要的功能进行优先级排序,然后一一交付;如何根据期望功能跟踪已交付功能,以此来了解其商业价值,以及软件开发流程和组织整体上是否健康。用本书中介绍的工具及理念来武装自己,你将可以帮助你的软件企业快速掌握现代工程实践,开始交付你期盼已久的成果。

大话重构 内容简介

《大话重构》运用大量源于实践的示例,从编码、设计、组织、架构、测试、评估、应对需求变更等方面,深入而多角度地讲述了我们应该如何重构,建设性地提出了高效可行的重构七步。

读完本书,实践重构不再卡壳,需求变更不再纠结。全面领悟重构之美,遗留系统不再是梦魇,自动化测试原来可以这样做。

《大话重构》帮助程序员告别劣质代码步入精妙设计,让遗留系统的维护者逐步改善原有设计,指导重构实践者走出困惑步步坚定。同时,也为管理者加强软件质量的管理与监督,提供了好的方法与思路。

大话重构 目录

第一部分 基础篇

第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  自动化测试--想说爱你不容易

4.3  我们是这样自动化测试的--JUnit下的HelloWorldTest

4.4  采用Mock技术完成测试

第二部分 实践篇

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

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

5.2  抽取方法的实践

5.3  最常见的问题

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

6.1  大对象的演化过程

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

6.3  单一职责原则(SRP)与对象拆分

6.4  合久必分,分久必合--类的归并

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

7.1  顺序编程的烦恼

7.2  代码重复与DRY原则

7.3  提高代码复用的方法

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

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

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

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

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

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

7.4  代码重复的检查工具

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

8.1  开放?封闭原则与可扩展点设计

8.2  过程的扩展与放置钩子--运用模板模式增加可扩展点

8.3  面向切面的可扩展设计

8.4  其他可扩展设计

第9章 第五步:降低程序依赖度

9.1  接口、实现与工厂模式

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

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

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

9.3  继承的泛滥与桥接模式

9.4  方法的解耦与策略模式

9.5  过程的解耦与命令模式

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

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

10.1  什么才是我们需要的分层

10.2  怎样才能拥抱需求的变化

10.3  贫血模型与充血模型

10.4  我们怎样面对技术的变革

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

11.1  第一步:分解大函数

11.2  第二步:拆分大对象

11.3  第三步:提高复用率

11.4  第四步:发现扩展点

11.5  第五步:降低依赖度

11.6  第六步:分层

11.7  第七步:领域驱动设计

第三部分 进阶篇

第12章 什么时候重构

12.1  重构是一种习惯

12.2  重构让程序可读

12.3  重构,才好复用

12.4  先重构,再扩展

12.5  变更任务紧急时,又该如何重构

第13章 测试驱动开发

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

13.2  测试驱动开发与重构

13.3  遗留系统怎样开展TDD

第14章 全面的升级任务

14.1  计划式设计vs.演进式设计

14.2  风险驱动设计

14.3  制定系统重构计划

第15章 我们怎样拥抱变化

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

15.2  领域模型分析方法

15.3  原文分析法

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

15.5  在遗留系统中的应用

第16章 测试的困境

16.1  重构初期的困局

16.2  解耦与自动化测试

16.3  开发人员,还是测试人员

16.4  建立自动化测试体系

第17章 系统重构的评价

17.1  评价软件质量的指标

17.2  怎样评价软件质量呢

结束语:重构改变了世界

附录

大话重构 精彩文摘

前面我们提到了,面对软件工业时代的到来,我们的软件企业陷入了一种更深的迷茫之中,一种“后有追兵,前有悬崖,进退两难”的境地。

后有追兵:面对维护了数十年之久的大型遗留系统,我们到底改还是不改?不改,面对越来越多的需求变更,我们维护的成本越来越高,变更变得越来越困难;面对不断涌现的新技术,我们的系统显得越来越丑陋与落后;面对越来越多的竞争者,我们面临着被市场淘汰的风险。

前有悬崖:原本运行得好好的软件系统,凑合一下还可以运行几年。一不小心改出问题了,企业立马就歇菜儿了,面对大量的用户投诉,企业四处救火,竞争对手趁火打劫,这是任何软件企业都不能承受的巨大风险。

难道真的“鱼与熊掌不能兼得”吗?真的没有一种方法,能够既保证我们的系统可以技术改造,又能有效地避免改造过程的风险吗?有,那就是系统重构。

1.1 什么是系统重构

提到重构,许多人都讳莫如深、敬而远之。那么什么是系统重构呢?大家可能有很多不同的看法:

1. 系统重构是那些系统架构师、技术大牛玩的高端玩意儿,咱普通屌丝不懂,跟咱没啥关系。

2. 系统重构就是改代码,大改特改那种,整个重来一遍那种,这个比较邪恶,比较容易改出事儿,还是不要轻易尝试为妙。

3. 我知道系统重构,也知道它能改善遗留系统,但我还是不敢轻易尝试,因为改出问题来怎么办,还是算了吧。

然而我认为,现在我们对系统重构有太多的误解,以至于我们还不怎么了解它,就已经将它拒之门外。什么是系统重构?它是一套严谨而安全的过程方法,它通过一系列行之有效的方法与措施,保证软件在优化的同时,不会引入新的BUG,保证软件改造的质量。这一点在我后面一步一步的拆解中,你可以慢慢体会到。

我们先看看系统重构的概念。系统重构,就是在不改变软件的外部行为的基础上,改变软件内部的结构,使其更加易于阅读、易于维护和易于变更①。

系统重构中一个非常关键的前提就是“不改变软件的外部行为”,这个前提非常重要,它保证了我们在改造原有系统的同时,不会为原系统带来新的BUG,以确保改造的安全。这里,什么是“为原系统带来新的BUG”?我们必须为其做出一个严格的定义,那就是“改变了软件原有的外部行为”。也许你对此有些不太赞同,改变了软件原有的外部行为,怎么就能武断地认为,是为原系统带来了新BUG 呢?为此我们来举个例吧。

假如一个系统的报表查询功能,原来在表格里的返回结果中,日期是这样表示的:“2013-2-18”。经过系统改造以后变成这样了:“2013-2-18 00:00:00”。这是BUG 吗?作为开发人员你可能认为这算什么BUG,但作为客户那就是BUG,因为它让表格变得难看,使用不再方便了。系统重构,对于客户来说应当是完全透明的。我们为之做了很多工作,而他们应当完全感觉不到它的存在。如果我们的重构做到了这一点,那么我们的重构就必然是安全的、可靠的、没有风险的。

更广泛一些来说,如果我们打开软件内部,保证系统中的每个接口与改造前是等价的,也就是说,其输入输出在改造前后都是一致的。当我们的每个改造都是这样进行的,则必然不会为系统带来新的BUG。这就是我们进行改造的保险索,它也是我现在所说的重构与以往那种拿着代码一阵瞎改的根本区别。

总而言之,系统重构不是那种冒着极大风险进行的代码修改,而是必须保证修改前后输入输出的一致,这就是我们说的“不改变外部行为”。为此,贯穿整个重构过程的是不断地测试。起初这种测试是手工测试,随后逐渐转变为自动化测试。每修改一点点就进行一个测试,再修改一点点。测试,就是系统重构的保险索。

图书网:大话重构pdf

继续阅读

→→→→→→→→→→→→→→→→→→→→查找获取

软件工程/开发项目管理

软件设计重构pdf

以4个设计原则为中心,全面呈现25种在软件项目中导致技术债务的设计坏味 提供一种独特的坏味命名方法,帮助理解坏味的由来并指出潜在重构方法 包含丰富的例证,展现糟糕设计实践的潜在坏味...
软件工程/开发项目管理

DevOps 最佳实践pdf

DevOps 最佳实践 作者: Bart de Best(巴特・德・贝斯特) DevOps 最佳实践 出版社:电子工业出版社 DevOps 最佳实践 内容简介 近年来,许多组织都体会到了使用敏捷方法的...
软件工程/开发项目管理

Android组件化架构pdf

Android走过的十个年头,其技术演进也是有迹可循的,本书作者基于自己在大型App架构的技术演进中成长的经历,将遇到的相关问题进行深入剖析,包括Android 组件化架构、模块化...
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

评论:1   其中:访客  1   博主  0
    • Henry
      Henry 9

      好书