我读经典(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 自动化测试——想说爱你不容易

自动化测试不是银弹，并不是所有代码都适合自动化测试。

另一个不适合自动化测试的就是要访问数据库的程序，因为它们执行的结果总是与数据库状态有关，无法获得稳定而可以不断复现的结果。

 

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

 

4.4 采用Mock技术完成测试

 

 

 

(本人微博： http://weibo.com/zhouzxi?topnav=1&wvr=5，微信号：245924426，欢迎关注！)