相信所有已经工作的同行，或者还在学校的同学，一定都或多或少得听说过“重构”这个词，我听一次听说“重构”这个词的时候，还是在上大二的时候，一位学长推荐的一本书叫《重构-改善即有代码》，正是在这本书中，我是第一次听说了重构这个词，从最初的不理解，到现在工作这么多年，有一定自己的理解，以及在工作中进行的一些重构的实践，今天这篇文章，就是重点跟大家分享一下，我对重构的一些理解。
首先，从字面意思上来理解，重构就是重新构建，那大家想一想，我们为什么要进行
呢，以有的代码让他放在哪里不动多好，改出问题来怎么办，这里就要明白我们重构的原因，以及希望通过重构能为我们带来什么收益，只有搞清楚这两点，才能明白我们到底需要不需要对代码进行重构。那有那些原因或进收益让我们有动力进行
呢？
- 有更好的实现方式去代替现有的实现。这个原因通常是我们进行重构最大的动力，对于技术人员说，这个也比较好理解，技术不停的发展，以前的一些实现放在现在并不一定是最优的，可能有一些更方便的库，或者API可以让我们更加好的实现一些功能。例如，以前我在写安卓代码创建List的时候，都是直接使用 new去自己创建，但有了guava库以后，我再也不自己去new了，而是使用guava库中的 Lists.newArrayList()去创建，再使用了kotlin以后,更是直接可以使用arraylistof()方法即可。因为技术的发展而出现的
，在我们的项目中数不胜数。 - 现有代码实现方式，不再方便扩展新的业务和功能，这个经常是被外界的业务倒逼着我们技术人员不得不去进行
，举个例子，以前我们写安卓页面的时候，UI和控制逻辑，都直接放在Activity或者Fragment中，这在以前app不那么大的时候，也是很合理的，但是，如果你的业务越来越复杂，功能越来越多，那么所以代码都放在Activity或者Fragment中，那就不再合理了，因为代码越来越大，对以后的维护和增加新功能带来严重的问题，基于此，不断的有非官方的MVP的开发模式和官方的基于jetpack的mvvm模式，让我们去
我们的代码。
其实重构的原因基于上也就是上面的两点，一个是我们技术的发展，导致我们需要去
我们的代码，这个属于内因，另一个就是业务的发展，到逼我们去重构我们的代码，属于外因，而无论是外因还是内因，最终重构的目的都是为了以更合理的方式去实现我们最终的代码。
在了解了我们有哪些场景下会去重构我们的代码基础上，那重构的内容具体又有哪些呢。我的答案是：万物皆可重构，没有什么是可以一成不变的。
- 功能代码，这个是显而易见的，也是我们最常要重构的地方，重构最开始提出来的时候，就是为了优化我们的功能代码。这个我们就不多说了。
- 构建脚本，无论是前端的js工程，还是移动端的安卓，IOS工程，还是后端的API工程等，最终都会有生成的产物，而为了生成这一产物，我们也会有专门的构建脚本或者构建代码，而随着工程的迭代，或者构建技术的发展，这一部分也经常是我们需要重构的部分，就拿安卓来说，从以前的ant构建发展到gradle构建，我们的工程构建代码也不得不发生变化，即使都到gradle以后，不同版本的gradle也会导致我们代码的重构。
- 工程架构，最早的工程都单一工程的架构，到发展为组件化的架构，再到现在的动态插件化架构，为了让我们的工程结构更加合理，我们也要不停的做出重构。
- 配置文件， 随着业务的发展，各种配置都会发生变化，而我们的配置文件也可以发生翻天腹地的变化，例如从简单的key-value文件，变成json配置，再到yaml配置。
- 各种脚本文件，一个工程往往会有许多工具脚本，而这部分也是要经常去重构的，一个简单的例子，安卓的多渠道打包脚本。
总结一下就是：没有什么是一成不变的，大到工程的功能代码，工程架构，小到工程中的一个工具脚本，都可能让我们去进行重构，而到底要不要去重构，就看我们上面讲到的哪两个原因，满足其中的一个，我们就可以考虑对其进行重构。
所以，从这里，我们也可以看出，重构对我们开发人员的重要性，每一个程序员都要有能够进行重构的能力和思想。这也是大厂对我们能力的一个要求，有这个能力，那你就是一个合格的程序员，而不是一个代码机器。
既然重构如此重要，有没有一个系统的课程可以让我们去完整的学习重构呢，欢迎大家来学习我在慕课网上发布的完整的重构课程：《实战企业级项目 践行App重构之路》。
随时随地看视频
