我读经典(5)：读《大话重构》迷你书有感

        近期。我在一个QQ群里面看到有人在讨论一本书，叫做《大话重构》。在闲暇之余，我下载了该书的电子版，是一本迷你书，仅仅包括了4 章内容。读完这本迷你书，结合自身的工作。我想说一下自己对于重构的看法。

       重构。是一把双刃剑，开发者不要轻易使用。举个样例来说，你如今正在从事某个行业的工作。但有人告诉你另外一个行业赚钱多并且快。于是你就非常纠结，究竟要不要改行呢？不改行吧，钱挣得少。改行吧，自己又是新手。对那个行业又不熟悉。这样的心理状态事实上就是开发者对于重构的态度，能够用“进退维谷”来形容。

1. 重构的原因

       依据书上所说，结合自身的经验，重构的原因如图1所看到的。

图1 重构的原因

2. 重构的原则

       重构的原则如图2所看到的。

图2 重构的原则

3. 重构的流程

       重构的流程如图3所看到的。

图3 重构的流程

        总的说来，对于程序来说，重构就相当于做一次大的手术，因此一定要认真对待。贯穿整个重构过程的是不断地測试、測试、再測试。我们须要不断地实践才干够对整个重构的流程得心应手。

附：《大话重构》迷你书经典语句

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

1.1 什么是系统重构

系统重构。就是在不改变软件的外部行为的基础上，改变软件内部的结构。使其更加易于阅读、易于维护和易于变更。

贯穿整个重构过程的是不断地測试。起初这样的測试是手工測试，随后逐渐转变为自己主动化測试。每改动一点点就进行一个測试，再改动一点点。測试。就是系统重构的保险索。

1.2 在保险索上走钢丝

重构的測试标准就仅仅有一个。就是与之前的功能全然保持一致。

QTP，Quicktest Professional的简称，是一种自己主动測试工具。使用QTP的目的是想用它来运行反复的手动測试。主要是用于回归測试和測试同一软件的新版本号。

一旦某个改动測试不通过。则还原回来。这样的一次一小步的改动模式，我们形象地称之为“小步快跑”。

1.3 大布局与小步快跑

大布局：全面地整理系统需求，全面地分析系统功能，再全面地设计系统、开发、測试。

这样一个过程往往会持续数月，花费大量的工作量。

系统重构应当避免大设计。而尽量採用一个一个连续不断的小设计。

这就是我们所说的“小步快跑”的设计模式。

小步快跑体现出了敏捷软件开发的特点——简单与高速反馈。

“两顶帽子”：一顶是仅仅重构而不新增功能，一顶是添加新的功能实现新需求。

另外一个问题就是及时反馈，落实到此地就是及时測试。

1.4 软件改动的四种动机

1. 添加新功能；

2. 原有功能有BUG。

3. 改善原有程序的结构；

4. 优化原有系统的性能。

现实世界有什么事物，这些事物都应当有什么行为。相互之间是什么关系，则我们在软件世界里就应当设计什么类、什么方法和它们之间的关联关系。

仅仅有这样的设计才是最易于为人所理解的设计，这就是“领域驱动设计”的思想。

为了有效提高软件的内部质量，我们在系统重构中应当做哪些事情呢？首先是提高软件的可读性，让它易于阅读；还有一件事情就是使软件易于维护、易于变更。

1.5 一个真实的谎言

需求变更才是我们去重构的主要动因。

当我们须要变更系统时，应该将变更的过程分为两个步骤：首先是不加入不论什么功能先重构我们的系统，使之适应新的需求。然后開始变更，实现新的需求。

“糟糕设计零容忍度”的策略，即先重构系统使之首先适应新的需求。再顺理成章去实现这些需求。

第2 章重构方法工具箱

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

等量变换。程序还是那些程序，运行的结果还是那些结果，但程序组织结构发生了变化，变得更加可读、可维护、易变更了。这就是重构的意义。

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

重构方法分为下面几个层次：方法的重构、对象的重构、对象间的重构、继承体系间的重构、组织数据的重构与体系架构的重构。

将通过凝视分段存放的各个代码段提取出来，形成单独的函数。这样的重构方法被称为“抽取方法”(Extract Method)。

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

3.1 大布局你伤不起

3.2 小设计而不是大布局

重构过程中正确的标准是我们的软件是否保持重构前的外部行为，推断的方法则是測试，不论是手工測试还是自己主动化測试。

小步快跑让我们每次重构的时候仅仅关注一个问题。运用一个重构手法去解决这一个问题。

同一时候，它要求我们对远期的规划不要过细。

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

小步快跑是一种逐步进化式的程序优化过程，它是重构思想的重要核心。

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

4.1 你不能没有保险索

系统重构。从自身的定义上就把其代码正确性的验证方式描写叙述得十分明确，那就是“不改变软件外部行为”。

系统重构的測试能够从两个层面来进行：系统測试与单元測试。

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

自己主动化測试不是银弹。并非全部代码都适合自己主动化測试。

还有一个不适合自己主动化測试的就是要訪问数据库的程序。由于它们运行的结果总是与数据库状态有关。无法获得稳定而能够不断复现的结果。

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

4.4 採用Mock技术完毕測试