首页 > 代码库 > 我读经典(5):读《大话重构》迷你书有感

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

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

       重构,是一把双刃剑,开发人员不要轻易使用。举个例子来说,你现在正在从事某个行业的工作,但有人告诉你另外一个行业赚钱多而且快,于是你就很纠结,到底要不要改行呢?不改行吧,钱挣得少;改行吧,自己又是新手,对那个行业又不熟悉。这种心理状态其实就是开发人员对于重构的态度,可以用“进退维谷”来形容。

1. 重构的原因

       根据书上所说,结合自身的经验,重构的原因如图1所示。

1 重构的原因

 

2. 重构的原则

       重构的原则如图2所示。

2 重构的原则

 

3. 重构的流程

       重构的流程如图3所示。

3 重构的流程

 

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

 

 

 

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

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

1.1 什么是系统重构

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

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

 

1.2 在保险索上走钢丝

重构的测试标准就只有一个,就是与之前的功能完全保持一致。

QTPQuicktest 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,欢迎关注!)