重构-改善既有代码的设计

一、什么事重构？

1.重构是对软件内部结构的一种调整，目的是在不改变外部行为的前提下，提高可理解性,降低修改成本。

2.重构是严谨、有序地对完成的代码进行整理从而减少出错的一种方法。

二、两顶帽子

利用重构技术开发软件时会把时间分配给两种行为： [重 构]与[添加新功能]

1.添加新功能时，不应该修改既有代码，只管添加新功能。

2.重构时你就不能再添加功能，只管改进程序结构。

3.两顶“帽子”可交替进行，一会重构，一会添加新功能。

三、为何重构？

1.改进程序设计

程序员为了快速完成任务，在没有完全理解整体  架构之前就修改代码，导致程序逐渐失去自己的结构。重构则帮助重新组织代码，重新清晰的体现程序结构和进一步改进设计。

2.提高程序可读性

容易理解的代码很容易维护和增加新功能。代码首先是写给人看的，然后才是计算机看的。

3.助你找到程序错误

重构是一个Code Review 和反馈的过程。在另 一个时段重新审视代码，会容易发现问题和加深对代码的理解。

4.助你提高编程速度

设计和代码的改进都可以提高开发效率，好的设计和代码都提高开发效率的根本。

5.提高设计和编码水平

对代码的重构，是快速提高设计和编码水平的方法。

四、何时重构？

1.增加新功能是一并重构

增加功能前需要理解修改的代码，如果发现代码不易理解且无法轻松增加功能，此时就需要对代码进行重构。

2.修补错误时一并重构

通过重构改善代码结构，能够帮助你找出BUG原因。

3.Review 代码时一并重构

有经验的开发人员Review代码时能够提出一些代码重构的建议。

五、何时不该重构？

1.代码实在太混乱，重构还不如重写

2.项目即将结束时避免重构

此时已经没有时间进行重构了，应该在早些时候进行重构。如果程序有必要重构，说明该项目已经欠下“债务”，

需要项目完成后进行偿还。

六、重构与设计

1.重构与设计彼此互补

良好的设计是重构的目标，重构弥补设计的不足。
2.重构使得设计方案更简单

如果选择重构，预先设计时候只需找出足够合理的解决方案，实现的时候对问题会进一步加深，此时可以重构成

最佳的解决方案。

3.重构能够避免过度设计

设计人员需要考虑将简单方案重构成灵活方案的难度。如果容易，只需实现简单方案。

七、代码的坏味道

1.重复的代码 (Duplicated Code)☆☆☆☆☆

重复代码是最常见的异味，往往是由于Copy & Paste 造成的。

重构方法：

a.重复代码在同一个类中的不同方法中，则直接提炼为一个方法

b.如果重复代码在两个互为兄弟的子类中，则将重复的代码提到父类中

c.如果代码类似，则将相同部分构成单独函数，或者用 Template Method 设计模式

d.重复代码出现在不相干的类中，则将代码提炼成函数或者放在独立的类中 

2.过长的函数(Long Method)☆☆☆☆☆

是面向结构程序开发带来的 “后遗症”，过长的函数降低可读性。

重构方法：

a.将独立的功能提炼成新函数

3.   过大类(Large Class)☆☆☆☆

过大的类使得责任不清晰。

重构方法：

a.将过大类的功能拆分成多个功能单一的小类 

4.过长的参数列(Long Parameter List)☆☆☆☆

过长的参数列难以理解，而且容易传错参数。

重构方法：

a.将参数列表用参数对象替换

5.发散式变化(Divergent Change)☆☆☆

一个类由于不同的原因而被修改。

重构方法：

a.将类拆分成多个，每个类只因为一种变化而修改

6.霰弹式修改(Shotgun Surgery) ☆☆☆☆

与发散式变化相反，遇到变化时需要修改许多不同的类。

重构方法：

a.将类似的功能放到一个类中

7.依恋情结(Feature Envy) ☆☆☆

函数对某个类的兴趣高过对自己所处的类，通常是为了取其他类中的数据。

重构方法:

a.将函数部分功能移到它感兴趣的类中

8.   数据泥团(Data Clumps) ☆☆☆

在多个地方看到相同的数据项。例如：多个类中相同的变量，多个函数中相同的参数列表，并且这些

数据总是一起出现。

重构方法:

将这些数据项放到独立的类中

9.分支语句(Swtich Statements) ☆☆☆☆

大量的分支、条件语句导致过长的函数，并且可读性差。

重构方法:

应将它变成子类或者使用 State和 Strategy模式

10.过度耦合的消息链(Message Chains) ☆☆☆

一个对象请求另一个对象，后者又请求另外的对象，然后继续。。。。，形成耦合的消息链。

重构方法:

a.公布委托对象供调用

11.过多的注释(Comments)☆☆

代码有着长长的注释，但注释之所以多是因为代码很糟糕。

重构方法:

a.先重构代码，再写上必要的注释

12.   夸夸其谈未来性(Speculative Generality) ☆☆☆

现在用不到，觉得未来可以用到的代码，要警惕。

重构方法:

a.将用不上的代码去掉

13.纯粹的数据类(Data Class) ☆☆☆

将数据类中数据以Public方式公布，没对数据访问进行保护。

重构方法:

a.将数据封装起来，提供Get/Set方法

以上是代码开发和程序维护过程中经常遇到的问题，并不是坏味道的全部。在开发中应避免出现坏味道。

在 Martin Fowler 著的《重构 –改善既有代码的设计》中列出了长达70条的重构名录，提供了具体重构的

方法和重构的技巧。将帮助开发人员一次一小步地修改代码，减少了开发过程中的风险。推荐大家有时间

可以看下这本书，相信今后对大家开发一定有很大的帮助。 下载地址：http://www.pin5i.com/showtopic-25572.html

这本书有段话我很喜欢，与大家分享下：
重构已经变成了我的另外一种生活方式，变成了我每天的面包与黄油，变成了我们整个团队的空气与水，

以至于无须到书中寻找任何神谕。