重构——程序猿的艺术
何为重构
重构：在不改变软件对外表现和行为的前提下修改已有代码使其易于理解，便于扩展
重构就是让代码易于程序猿理解。在重构的世界里代码是写给程序猿看的而非写给机器看，我们会忽视性能而专注于让代码对程序猿更友好（先让代码跑通，再去重构，最后才考虑性能优化）
为什么要重构
- 在添加功能前重构，可以时原有的代码更易扩展，简化功能添加难度
- 在改bug前重构，可以优化代码的结构，使逻辑更加清晰，更容易找出bug
- 在评审代码时（无论是自己的还是别人的代码都行）进行重构，可以加深对代码逻辑的理解
重复一遍：
| 重构时机 | 好处 |
|---|---|
| 添加功能前 | 更易扩展 |
| 改bug前 | 更易找出bug |
| 评审代码时 | 加深理解 |
怎么重构
看图：
第一步 建立测试框架
测试框架是判断重构成功与否的关键，再重复一遍：
重构：在不改变软件对外表现和行为的前提下修改已有代码使其易于理解，便于扩展
重构不能改变代码对外的表现和行为，测试框架正是要测试重构是否改变了代码的对外接口，如果不能通过测试，必须对重构进行修复（回滚到重构之前）
第二步 寻找代码坏味
代码坏味（Bad Smell），出自《重构——改善既有代码的设计》的作者，作者认为代码的不合理设计就像婴儿的尿布散发出来的Bad Smell一样，当你闻到它的时候，就应该警惕：该给代码换尿布了
我们要重构代码，首先要找出需要重构的地方，作者总结了几种特殊“味道”的Bad Smell，我把它写在了【怎么重构】的下面（代码坏味）
第三步 代码重构
使用针对代码坏味的重构手段对其进行重构即可
第四步 测试
使用第一步建立的测试框架对重构进行测试
重构可不是写Bug
代码坏味
我只收录了《重构——改善既有代码的设计》中一部分常见的代码坏味，更多的请查看原书
我极力推荐给大家这本书：世界软件开发大师Martin Fowler的《重构——改善既有代码的设计》
| 坏味 | 表现 | 对应的重构手段 |
|---|---|---|
| 重复代码块 | 相同代码重复出现 | 抽取方法 |
| 方法过长 | 方法体长度超过30行 | 抽取方法 |
| 方法参数过多 | 方法所需的参数超过3个 | 使用对象封装参数集 |
| 临时变量存在 | 代码中有临时变量 | 使用查询方法取代临时变量 |
| switch语句存在 | 代码中有switch分支 | 使用多态取代switch分支 |
| 类过长 | 类的长度超过100行 | 转移成员变量和函数<br />抽取类 |
| 发散式变化 | 引发一个类修改的原因不只一个 | 抽取类 |
| 发散式修改 | 一个类修改，引发修改的其他类不止一个 | 抽取类 |
| 数据依赖&过度亲密 | 一个类过多调用另一个类的成员和函数（甚至超过了拥有成员和函数的类） | 转移成员变量和函数 |
重构手段
等我把这些文章全写完发了，再给你们提供链接
-
到处都是重复的代码？方法体又臭又长看不懂？快来试试抽取方法（Extract Method）吧，保证药到病除！
-
使用对象封装参数集
答应我，别再给方法弄一长溜的参数了，好吗？
-
使用查询方法取代临时变量
你这方法里怎么这么多临时变量？我完全记不住每个变量是用来干什么的！
-
使用多态取代switch分支
“来看看外包老哥写的超长switch语句”这种文章又登上首页了
-
及时打断if条件分支
外包老哥总是被黑的幕后黑手找到了！
-
转移成员变量和函数
道理我都懂，可是你一直在用的成员变量为什么要让我负责管理？
-
抽取类
总觉得，是时候new一个替身出来帮我干活了
-
将数据的处理函数转移给持有数据的类
或许，这个锅应该由你来背
-
向父类转移成员变量和函数
所有子类都需要做的事，为什么不让父类直接做了？
-
注意集合型成员变量的get/set方法！
有人动了我的集合对象，可是我却不知道！
