重构——程序猿的艺术

何为重构

重构：在不改变软件对外表现和行为的前提下修改已有代码使其易于理解，便于扩展

重构就是让代码易于程序猿理解。在重构的世界里代码是写给程序猿看的而非写给机器看，我们会忽视性能而专注于让代码对程序猿更友好（先让代码跑通，再去重构，最后才考虑性能优化）

为什么要重构

• 在添加功能前重构，可以时原有的代码更易扩展，简化功能添加难度
• 在改bug前重构，可以优化代码的结构，使逻辑更加清晰，更容易找出bug
• 在评审代码时（无论是自己的还是别人的代码都行）进行重构，可以加深对代码逻辑的理解

重复一遍：

重构时机	好处
添加功能前	更易扩展
改bug前	更易找出bug
评审代码时	加深理解

怎么重构

看图：

第一步 建立测试框架

测试框架是判断重构成功与否的关键，再重复一遍：

重构：在不改变软件对外表现和行为的前提下修改已有代码使其易于理解，便于扩展

重构不能改变代码对外的表现和行为，测试框架正是要测试重构是否改变了代码的对外接口，如果不能通过测试，必须对重构进行修复（回滚到重构之前）

第二步 寻找代码坏味

代码坏味（Bad Smell），出自《重构——改善既有代码的设计》的作者，作者认为代码的不合理设计就像婴儿的尿布散发出来的Bad Smell一样，当你闻到它的时候，就应该警惕：该给代码换尿布了

我们要重构代码，首先要找出需要重构的地方，作者总结了几种特殊“味道”的Bad Smell，我把它写在了【怎么重构】的下面（代码坏味）

第三步 代码重构

使用针对代码坏味的重构手段对其进行重构即可

第四步 测试

使用第一步建立的测试框架对重构进行测试

重构可不是写Bug

代码坏味

我只收录了《重构——改善既有代码的设计》中一部分常见的代码坏味，更多的请查看原书

我极力推荐给大家这本书：世界软件开发大师Martin Fowler的《重构——改善既有代码的设计》

坏味	表现	对应的重构手段
重复代码块	相同代码重复出现	抽取方法
方法过长	方法体长度超过30行	抽取方法
方法参数过多	方法所需的参数超过3个	使用对象封装参数集
临时变量存在	代码中有临时变量	使用查询方法取代临时变量
switch语句存在	代码中有switch分支	使用多态取代switch分支
类过长	类的长度超过100行	转移成员变量和函数 抽取类
发散式变化	引发一个类修改的原因不只一个	抽取类
发散式修改	一个类修改，引发修改的其他类不止一个	抽取类
数据依赖&过度亲密	一个类过多调用另一个类的成员和函数（甚至超过了拥有成员和函数的类）	转移成员变量和函数

重构手段

等我把这些文章全写完发了，再给你们提供链接

• 抽取方法

  到处都是重复的代码？方法体又臭又长看不懂？快来试试抽取方法（Extract Method）吧，保证药到病除！

• 使用对象封装参数集

  答应我，别再给方法弄一长溜的参数了，好吗？

• 使用查询方法取代临时变量

  你这方法里怎么这么多临时变量？我完全记不住每个变量是用来干什么的！

• 使用多态取代switch分支

  “来看看外包老哥写的超长switch语句”这种文章又登上首页了

• 及时打断if条件分支

  外包老哥总是被黑的幕后黑手找到了！

• 转移成员变量和函数

  道理我都懂，可是你一直在用的成员变量为什么要让我负责管理？

• 抽取类

  总觉得，是时候new一个替身出来帮我干活了

• 将数据的处理函数转移给持有数据的类

  或许，这个锅应该由你来背

• 向父类转移成员变量和函数

  所有子类都需要做的事，为什么不让父类直接做了？

• 注意集合型成员变量的get/set方法！

  有人动了我的集合对象，可是我却不知道！

技术不分领域，思想一脉相承，欢迎访问橙味菌的博客