代码重构 & 代码中的坏味道

1.重构

1.1 为什么要重构

1.1.1 改进程序设计

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

1.1.2 提高程序可读性

容易理解的代码很容易维护和增加新功能。代码首先是写给人看的，
然后才是计算机看的。
  重构是一个Code Review 和反馈的过程。在另一个时段重新审视代码，
会容易发现问题和加深对代码的理解。

1.2 利用重构技术开发软件时会把时间分配给两种行为：

1.2.1 重 构

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

1.2.2 添加新功能

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

1.3 何时重构

1.3.1 增加新功能时一重构

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

1.3.2 修补错误时一重构

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

1.3.3 Review 代码时一重构

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

1.4 何时不该重构

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

1.4.2 项目即将结束时避免重构

2.代码的坏味道

2.1 重复的代码(Duplicated Code)

重构方法：
2.1.1 重复代码在同一个类中的不同方法中，则直接提炼为一个方法。
2.1.2 如果重复代码在两个互为兄弟的子类中，则将重复的代码提到父类中。
2.1.3 如果代码类似，则将相同部分构成单独函数，或者用 Template Method 设计模式。

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

2.2 过长的函数(Long Method)

是面向结构程序开发带来的 “后遗症”，过长的函数降低可读性。
重构方法:
  将独立的功能提炼成新函数。

2.3 过大类(Large Class)

过大的类使得责任不清晰。
重构方法：
  将过大的类的功能拆分成多个功能单一的小类。

2.4 过长的参数列表(Long Parameter List)

过长的参数列难以理解，而且容易传错参数。
重构方法：
  将参数列表用参数对象替换。

***2.5 发散式变化(Divergent Change)

一个类由于不同的原因而被修改
重构方法：
  将类拆分成多个，每个类只因为一种变化而修改。  
eg:一个包含有多个业务逻辑的代码，尽量拆分成多个功能相对独立的小类

***2.6 霰弹式修改(Shotgun Surgery)

与发散式变化相反，遇到变化时需要修改许多不同的类。
重构方法：
  将类似的功能放到一个类中

2.7 依恋情结(Feature Envy)

函数对某个类的兴趣高过对自己所处的类，通常是为了取其他类中的数据。(类中方法的界限)
重构方法：
  将相关的功能移动到它感兴趣的类中。

2.8 数据泥团(Data Clumps)

在多个地方看到相同的数据项。
eg:多个类中相同的变量，多个函数中相同的参数列表，并且这些数据总是一起出现。
重构方法：
  将这些数据项，独立到类中。

2.9 分支语句(Swtich Statements)

大量的分支，条件语句导致过长的函数，最后导致代码可读性差。
重构方法：
  将分支变成子类，或者使用State 和 Strategy模式。

2.10 过度耦合的消息链(Message Chains)

一个对象请求另一个对象，后者又请求另外的对象，然后继续。。。。，形成耦合的消息链。
重构方法：
  公布委托对象供调用。

2.11 过多的注释(Comments)

代码有着长长的注释，但注释之所以多是因为代码很糟糕
重构方法：
  写上必要的注释，尽量让代码不用注释就比较易读。

3.重构实战(TODO)

参考：
重构:改善既有代码的设计