重构原则

何为重构

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

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

重构不止是代码整理，它提供了一种高效且受控的代码整理技术

也就是在不改变代码原有功能的基础上、修改代码结构，使代码结构更合理、更易升级维护。

为何重构

• 改进软件设计：如果没有重构，程序的设计会逐渐变质，重构更像是在整理代码，你所做的就是让所有的东西回到应处的位置上。
• 帮助找到bug：对代码进行重构，可以深入理解代码的作为，在搞清楚程序结构的同时，想不把bug揪出来都难。
• 提高编程速度：良好的设计是快速开发的根本，改善设计、提高可读性，减少错误，这些都是提高质量。

其实是在解决乱的问题同时，也解决了脏和差的问题。

何时重构

任何情况下我都反对专门拨出时间进行重构。重构本来就不是一件应该特别拨出时间做的事情，重构应该随时随地的进行。

三次法则

第一次做某件事情是只管去做；第二次做类似的事情会产生反感；第三次再做类似的事，你就应该重构

• 最常见的重构时机是想给软件添加新特性的时候、其实就是在做迭代

重构的另个一原动力是：代码的设计无法帮助我轻松的添加所需要的特性

因为如果难以添加新特性，也就是难以加代码（做迭代），其实就是说明了现有的代码结构不合理。

• 修改错误的时候
• review代码时的重构

随时随地发现代码结构不合理，都可以做一些调整。这都叫代码重构。

间接层和重构

• 计算机科学是这样一门科学：它相信所有的问题都可以通过增加一个间接层来解决。

大多数重构都为程序引入了更多的间接层，重构往往把大型的对象拆成多个小型的对象，把大型的函数拆成多个小型的函数。

我们平时是怎么判断代码的好与坏（结构）呢？

其实就是去看代码是否清晰、有没有做足够合理的抽象。

但是，间接层是一把双刃剑。每次把一个东西分成两份，你就需要多管理一个东西。如果某个对象委托另一个对象，后又委托另一个对象，程序会愈加难以阅读。

我们把代码一抽象，确实代码会清晰很多。但是本质上，代码行数并没有少，而且还分散了。

何时不该重构：有时候既有代码实在太混乱，重构它还不如重新写一个来得简单。

重写而非重构的一个清楚讯号是：现有代码根本不能正常运作。

既然程序会愈加难以阅读，那我们还要重构吗？还要做抽象吗?

本质上还是为协同开发做的考虑，目的是让别人读懂。

代码的坏味道

重复代码

如果你在一个以上的地点看到相同的程序结构，那么可以肯定：设法将它们合二为一，程序会变得更好 。

1. 同一个类中有相同的表达式：提炼出重复的代码，然后让两个地方都调用被提炼出来的那一段代码（私有方法）；
2. 两个互为兄弟的子类内含有相同的表达式：提炼出相同代码，将它推入超类内；
3. 两个毫不相干的类中出现：将重复的代码提炼到一个独立的类中。

过长的类

拥有短函数的对象活得比较好、比较长。间接层所能带来的全部利益——解释能力、共享能力、选择能力——都是由小型函数支持的。

抽象的部分，一定要具备原子性。原子性就是基础能力，更容易被复用。也即是代码越长，越难复用。这个短与长的边界，就是“能力”。

每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立的函数中。

如何确定提炼哪一段代码？寻找注释是一个很好的技巧。它们通常能指出代码用途和实现手法之间的语义距离。如果代码前方有一行注释，就是提醒你：可以将这段代码替换成一个函数。

条件表达式和循环常常也是提炼的信号。

解释：

首先是，当你需要加注释的时候，代表：

• 这是一块独立的功能
• 不易于理解

这两个特征，其实也是抽象的特征。

过大的类

这里讲的类的边界。

如果想利用单个类做太多的事情，其内往往就会出现太多实例变量。

类内如果有太多代码，也是代码重复、混乱并最终走向死亡的源头。

代码如果量大的异常，那大概率是有重复的东西。

标签：重构,函数,对象,代码,之道,抽象,间接
来源： https://blog.csdn.net/GBS20200720/article/details/122765019