软件中的重构

本文主要是介绍软件中的重构，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、什么是重构

在现实世界里，经常会看到一些现象。举一个简单的例子，自己的家里可能时间久了，觉得家俱的摆设、风格或者位置等会动一动。如果觉得整体的家庭的环境都不太喜欢了，或者说让居住者不舒适了，还可能找人重新装修。这就可以理解成重构。它是对房屋内部的装饰的一种重构。当然，如果整个房子有些老旧，甚至可能有些年久失修的风险，但发现房子的基础和墙壁大梁等还挺结实，那么也可以再次在此基础上进行加固或者拆除不好的部位重新换上新的部分。这也可以理解成对房屋的重构。
那么有人会问，如果房屋需要推倒重建呢？那就不是重构了，那是再建。映射到代码世界里就是放弃原代码，但为了实现原功能仍然需要重新编写一个新的软件来实现功能。这样也就明白了，重构是什么内涵。所以可以将其定义为：“重构（Refactoring）就是通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性”。
为什么需要重构呢？这需要从软件的设计和实际需求的发展进行说明。大家都知道，事物是不断发展变化的，需求也会因此不断的动态的修改（含删除）和增加。所以在实际的需求开发，也就是说把需求转化为软件的实际代码的过程中，无论是从设计人员或是开发人员，都不可能完全把握实际的需求的准确性或者说这个需求只是某个点的切片时刻的准确性和完整性。这就会引出一个问题，真正的设计师不可能不为软件设计保留冗余和开放的接口。而这正是后期开发或者维护人员可能将其堆迭成“屎山”的后门。同样由于各种原因（比如沟通不畅等），可能设计风险本身就存在，这就导致了起初的设计可能就不完全符合实际的需求。
同样，做为开发人员，为了实现设计，不光需要考虑技术还要考虑现实世界中的进度、人力和各种其它不可控的情况。那么，在真正实现代码时，就不可能精益求精的实现这个过程。而大行其道的类似敏捷开发之类的模式也不会允许开发者精细化的开发。而不不断的迭代的过程中，虽然大部分会朝着更优的方向前进，但实际上，也有可能朝着风险更大的方向前进。这其实就是误差累积造成的错误，我们不能假设每次都能校正误差。它体现在实际的开发中，可能是没有或者注释不清晰；代码质量不高；不处理相关警告或者一些暂时无效的问题；没有或者测试很少等等。而设计师在设计时同样会体现出对设计的原则的违背以及接口设计的不合理等等。诸如此类，都会在未来的时间内不断的累积，形成代码的“坏味道”。最终会造成维护成本的上升和系统整体功能的下降（比如经常宕机等），特别是安全风险可能与日俱增。
假如代码的坏味道并不影响代码的运行与维护，这就不是一个问题。但其实这是一个悖论，这样的代码一定是会影响运行和后期维护的。这正如一个人，不可能到老年了还一如年轻时健康有力。即使好的设计好的维护，看上去优秀的代码，仍然可能已经不再适应环境了。只是说它的应用时间更长，维护更简单。但是，软件的生命周期一如人的生命周期，也是不可抗拒的。
可以这样理解，重构就是不断的锻炼身体、保养身体，使人在漫长的岁月中，虽然老去，但仍然健康，不需要过多的外人照顾。也就是医疗领域中常说的，预防大于治疗。

二、重构的目的和原则

重构非常重要，它的目的指向性也非常明显即提高代码的质量和代码的设计，体现在外表就是让代码容易维护、减少Bug以及提高可扩展性和维护性，说成大白话就是让软件好用。这个好用，既体现在使用者方面，也体现在开发者方面。特别是在后者，会使得新功能的开发（即扩展性）和维护上极大的增加方便快捷性。
但是，代码重构要遵循下面的原则：
1、保证代码的安全准确
这个非常容易理解，重构的新代码不能无法正确运行，这就失去了重构的基本目的。
2、一次只重构一个单元
这和设计原则一致，重构不能一开始就大规模的展开，需要小步快跑，宁可断其一指，不能伤其十指。而这个单元可以是一个函数、一个类或者一个接口等等。宜小不宜大。
3、保证代码的清晰易读
重构的目的之一就是可维护性，所以代码的可读性是必须的。

三、重构的层次

一般来说，可能大家的认知重构只是对代码的优化。其实不然，从不同的角度看，重构可以划分成不同的层次，比如从规模上可以划分出小规模重构和大规模构。这里从常见的开发角度将重构可以划分成三个层次：
1、代码重构
这个大家非常容易理解，就是将代码优化和拆解等。或者将变量控制起来不使用指针等等。
2、设计重构
设计上的类的大小、功能以及接口变化等等都可以根据变化进行重新考虑和引入设计模式
3、架构重构
这个就是从宏观上看整个软件项目了，即对原有程序的整体层次、模块的划分以及不同框架间的通信方式的控制和是否引入新的通信形式等等。一般来说，这种规模的重构，就非常考验领导的决心了。

四、重构的引入

重构既然如此重要，那么什么时候需要引入它呢？总结一些书本和实际的开发经验可以很明白的知道时机：
1、出现了难以解决的痛点或者热点
2、出现了明确的扩展需求但原程序支持不好
3、重构的风险可控

其实，重构非常多的时候都不是技术需求变化引起的，而是实际环境中外力需要引起的。举一个极端的例子，新来的领导觉得原来的代码不好，要求重构。这种现象很多，比如一个新架构师到了一个新的公司，可能就有动机非常想对项目进行重构。

五、重构的路线

重构需要小步快跑，持续迭代进行，它可以分成几种路线进行：
1、代码
优化从代码入手，优化代码，比如拆解大函数、大类；杜绝或减少全局变量；对属性函数增加常量控制；消除类似或重复代码；删除死代码等等。
2、接口
重新组织接口的位置、调用条件以及相关参数。重新组织接口的功能和相应权限等等。引入设计模式等等。
3、文件
减少文件，公用化头文件或者相关预定义文件。重新布置文件的归属和相关的组织关系等等。特别是某些动态生成的文件和外部调用的相关的文件等。
4、库和框架
精简库的使用和调用方式（如动态库和静态库的选择等），对框架在项目中的重要性进行评估，是否必须或者有简单的更替框架或直接删除用内部代码（反过来亦可）替代等等。

六、具体的重构方法

下面举出一些常见的重构的方法和手段，当然还有很多其它的，请大家自行补充和理解：
1、管理变量
包括重命名变量便于理解和风格统一；整理全局变量和静态变量，根据情况进行封装。
2、对函数进行重构
包括拆解、组合函数。但原则就是功能单一，代码量小。包括对引入内联函数等的性能的关切以及常量控制等限制性要求；对分支进行优化等等。
3、管理类
包括类名称的风格和理解性，继承的控制，接口的暴露，变量的暴露；类的依赖关系、功能控制等。
4、接口
对接口进行管理，包括功能的单一化，参数的控制以及相关设计的合理性等。
5、引入设计模式和设计原则
即对上述的前四条的应用进行抽象和再次封装，并根据相关的设计原则进行功能和行为的划分处理。
6、拆分逻辑
即对相关的业务逻辑、功能逻辑和界面逻辑以及数据逻辑等进行拆分，严格意义讲这仍然属于设计原则的范畴。但重点在业务逻辑和功能逻辑在拆分完成后可以引入更多设计模式和设计原则，通过各种技术实现对其的封装。
7、优化设计分层和模块划分
即对原有的设计层次划分以及模块划分不符合当前需求的部分进行合理的删减增加。使得各个层次间解耦和依赖最小化；降低各个层及模块间的无效接口调用。
8、架构
这个非常典型的需求就是尽可能降低架构的复杂性，提高整体架构的扩展性和安全性。从而达到提高性能和高可用性。