重构原则
何为重构
对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
另一种解释是：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
重构不止是代码整理，它提供了一种高效且受控的代码整理技术
也就是在不改变代码原有功能的基础上、修改代码结构，使代码结构更合理、更易升级维护。
为何重构
- 改进软件设计：如果没有重构，程序的设计会逐渐变质，重构更像是在整理代码，你所做的就是让所有的东西回到应处的位置上。
- 帮助找到bug：对代码进行重构，可以深入理解代码的作为，在搞清楚程序结构的同时，想不把bug揪出来都难。
- 提高编程速度：良好的设计是快速开发的根本，改善设计、提高可读性，减少错误，这些都是提高质量。
其实是在解决乱的问题同时，也解决了脏和差的问题。
何时重构
任何情况下我都反对专门拨出时间进行重构。重构本来就不是一件应该特别拨出时间做的事情，重构应该随时随地的进行。
三次法则
第一次做某件事情是只管去做；第二次做类似的事情会产生反感；第三次再做类似的事，你就应该重构
- 最常见的重构时机是想给软件添加新特性的时候、其实就是在做迭代
重构的另个一原动力是：代码的设计无法帮助我轻松的添加所需要的特性
因为如果难以添加新特性，也就是难以加代码（做迭代），其实就是说明了现有的代码结构不合理。
- 修改错误的时候
- review代码时的重构
随时随地发现代码结构不合理，都可以做一些调整。这都叫代码重构。
间接层和重构
- 计算机科学是这样一门科学：它相信所有的问题都可以通过增加一个间接层来解决。
大多数重构都为程序引入了更多的间接层，重构往往把大型的对象拆成多个小型的对象，把大型的函数拆成多个小型的函数。
我们平时是怎么判断代码的好与坏（结构）呢？
其实就是去看代码是否清晰、有没有做足够合理的抽象。
但是，间接层是一把双刃剑。每次把一个东西分成两份，你就需要多管理一个东西。如果某个对象委托另一个对象，后又委托另一个对象，程序会愈加难以阅读。
我们把代码一抽象，确实代码会清晰很多。但是本质上，代码行数并没有少，而且还分散了。
何时不该重构：有时候既有代码实在太混乱，重构它还不如重新写一个来得简单。
重写而非重构的一个清楚讯号是：现有代码根本不能正常运作。
既然程序会愈加难以阅读，那我们还要重构吗？还要做抽象吗?
本质上还是为协同开发做的考虑，目的是让别人读懂。
代码的坏味道
重复代码
如果你在一个以上的地点看到相同的程序结构，那么可以肯定：设法将它们合二为一，程序会变得更好 。
- 同一个类中有相同的表达式：提炼出重复的代码，然后让两个地方都调用被提炼出来的那一段代码（私有方法）；
- 两个互为兄弟的子类内含有相同的表达式：提炼出相同代码，将它推入超类内；
- 两个毫不相干的类中出现：将重复的代码提炼到一个独立的类中。
过长的类
拥有短函数的对象活得比较好、比较长。间接层所能带来的全部利益——解释能力、共享能力、选择能力——都是由小型函数支持的。
抽象的部分，一定要具备原子性。原子性就是基础能力，更容易被复用。也即是代码越长，越难复用。这个短与长的边界，就是“能力”。
每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立的函数中。
如何确定提炼哪一段代码？寻找注释是一个很好的技巧。它们通常能指出代码用途和实现手法之间的语义距离。如果代码前方有一行注释，就是提醒你：可以将这段代码替换成一个函数。
条件表达式和循环常常也是提炼的信号。
解释：
首先是，当你需要加注释的时候，代表：
- 这是一块独立的功能
- 不易于理解
这两个特征，其实也是抽象的特征。
过大的类
这里讲的类的边界。
如果想利用单个类做太多的事情，其内往往就会出现太多实例变量。
类内如果有太多代码，也是代码重复、混乱并最终走向死亡的源头。
代码如果量大的异常，那大概率是有重复的东西。
标签：重构,函数,对象,代码,之道,抽象,间接 来源： https://blog.csdn.net/GBS20200720/article/details/122765019
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。