优雅编程之这样重构代码，你就“正常”了（十八）

开心一笑

【老婆问老公：你喜欢玩水还是喜欢玩火？
老公：我喜欢玩火。
老婆：那以后，饭就由你来煮。
老公：不不不，我喜欢玩水。
老婆：那以后的碗就由你来洗。
老公：瞬间石化。…】

【男孩：我感动天，感动地，怎么感动………
女孩：你要是敢动我，我，我，我就打死你。
男孩：好好的一首情歌。……】

提出问题

项目开发中如何进行重构？？？

解决问题

这是《重构 改善既有代码的设计》中第1~5章我觉得比较重要的知识点。事实上只要看第1章的例子，第2~4章个人建议可以略过，没什么用.

重构的第一步

每当我要进行重构的时候，第一个步骤永远是相同的。即建立一个可靠的测试环境。

分解和重组

代码块越小，代码的功能就越容易管理，代码的处理和移动也就越轻松。

首先，我得在代码里找出函数内的局部变量和参数。任何不会被修改的变量，都可以被我当成参数传入新的函数，至于会被修改的变量，就需要格外的小心。

正和一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解代码才是优秀的程序员。

去除临时变量

利用多态取代

何为重构：

名词：重构，对软件内部结构的一种调整，目的是在不改变，软件可观察行为的前提下，提高其可理解性，降低其修改成本。

动词：重构，使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。

两顶帽子

添加新功能以及重构。

添加新功能就添加新功能，先不要去重构，重构你就好好重构，先不要去添加新的功能。

为何重构

原因我就不说了，反正就他妈好。

何时重构

三次法则：第一次做某件事时只管去做，第二次做类似的事时会产生反感，但无论如何还是可以去做，第三次再做类似的事，你就应该重构。

• 添加功能时重构
• 修补错误时重构
• 复审代码时重构

以下是一些坏代码味道：符合下面就该重构了

• Duplicated Code(重复代码)

• Long Method(过长函数)

• Large Class（过大的类）

• Long Parameter List（过长的参数列表）

• Divergent Change（发散式变化）：当你看着一个类说：如果新加入一个数据库，我必须修改这三个函数，如果新出现一种金融工具，我必须修改这四个函数。那么此时也许将这个对象分成两个会更好。

• Shotgun Surgery(弹式修改)：
  如果遇到哪种情况，你都必须在很多不同的类内作出，许多小修改。那就是坏的味道。这时候你需要把所有需要修改的代码放进同一个类。如果眼下没有合适的类可以安置这些代码，就创建一个。

• Feature Envy（依恋情节）

函数对某个类的兴趣高过对自己所处类的兴趣，是时候考虑这个函数到底应该放在什么位置了。

对象技术的全部要点：这是一种将数据和对数据的操作行为包装在一起的技术。

最根本的原则是，将总是一起变化的东西放在一块。

数据和引用这些数据的行为总是一起变化的。

• Data Clumps（数据泥团）

减少字段和参数的个数，当然可以去除一些坏味道。但更重要的是，一旦拥有新对象，你就有机会让程序散发出一种芳香。

• Primitive Obsession（基本类型偏执）

将原本单独存在的数据值替换为对象，从而走出传统的洞窟，进入炙手可热的对象世界。

编写小对象，如表示范围的Range

• Switch Statements(switch 惊悚现身)

面向对象程序的一个最明显特征：少用switch（或case）语句。

看到switch语句，就应该考虑以多态来替换它。

• Parallel Inheritance Hierarchies（平行继承体系）

每当你为某个类添加一个子类，必须也为另一个类相应增加一个子类，大多数时候你会发现，某个继承体系的类名前缀和另一个继承体系的类名前缀完全相同。是时候分离，为两个继承体系了。

• Lazy Class（冗赘类）

你所创建的每个类，都得有人去理解它，维护它，这些工作都是要花钱的。如果一个类的所得不值其所价，它就应该消失。

• Speculative Generality（夸夸其谈未来性）

无用的抽象类，无用的预留参数。

• Temporary Field（令人迷惑的暂时字段）

某个类的实例变量仅为某种特定情况来设，某个函数的参数，为了方便声明为某个类的成员，而仅仅在这一个函数中使用。

• Message Chains（过度耦合的函数）

现一个对象请求另一个对象，在向后者请求另一个对象。

• Middle Man（中间人）

你也许会看到某个类接口，有一半的函数都委托给其他类，这样就是过度运用。

无用的委托，过多的中间层。

• Inappropriate Intimacy(钾昵关系)

类不要过度亲密，一个类过一关注另一个类的成员。

• Alternative Classes with Different Interfaces(曲同工的类)

两个函数做同一件事，却有着不同的类名

• Incomplete Library Class(不完美的类库)

• Data Class（纯稚的数据类）

或许可以通过移动方法把和这个数据对相关的操作一过来。

• Refused Bequest（被拒绝的遗赠）

• Comments（过多的注释）

读书感悟

来自几米《月亮忘记了》

• 每个人都有一个像月亮一样的爱人，因为这个爱人，我们拥有守护的能力。

• 记住的，是不是永远不会消失？ 我守护如泡沫般脆弱的梦境， 快乐才刚开始，悲伤却早已潜伏而来。

• 生命中，不断地有得到和失落。于是，看不见的，看见了；遗忘的，记住了。
  生命中，不断地有人离开或进入。于是，看见的，看不见了；记住的，遗忘了。
  然而，看不见的，是不是就等于不存在？记住的，是不是就不会消失？

其他

如果有带给你一丝丝小快乐，就让快乐继续传递下去，欢迎转载，点赞，顶，欢迎留下宝贵的意见，多谢支持！