1. 概述
个人觉得，在项目开发一开始，就需要考虑框架如何搭建，使用MVC还是MVP还是其他的、联网请求、处理图片、处理缓存等等这些问题，在开发前期，这些东西都是一定要考虑进去的，如果在开发后期，代码质量下降、难以阅读、难以维护，导致迭代困难，造成恶性循环，那么到最后可能会需要重构代码，那么接下来我们就从什么情况下需要重构代码、重构的目的、如何去重构这3个方面来进行分析。
2. 什么情况下需要重构代码？
2.1：结构混乱
1>：代码没有层次之分，乱写一通，没有一条清晰的业务线；
2>：各个模块之间代码互相掺杂；
3>：代码中的MVC、MVP、MVVM等多个框架存在；
4>：不太规范，各个模块之间代码可能不一样；
2.2：可读性差
1>：一个类的代码太长，方法的代码太长；
2>：冗余代码、重复代码太多；
3>：维护困难，牵一发而动全身，修改一个地方，改动的地方太多；
4>：版本迭代时，新添加一个或者几个功能时，需要修改原来的代码，而且修改大量的代码；
3. 重构的目的，为什么需要重构？
重构的目的就是为了提高代码的质量，有以下几点：
3.1：可读性高
1>：命名规范，见名知意；
2>：需要添加一定的注释；
3>：每一个类的代码不要太多，逻辑一定要明确，结构一定要清晰；
4>：把公用的代码都尽量抽取成方法，抽取成工具类，可以在其他地方使用，目的就是尽量不要写冗余、重复的代码；
3.2：可维护性
1>：对于文字、文字的颜色、文字的大小，即就是text、textSize、textColor，都尽量写在string、dimens、color下边，然后在Xml文件中直接引用即可，不要直接把具体的文字、颜色、大小写到Xml文件中；
2>：代码尽可能的复用、尽可能的复用、尽可能的复用；
3>：开发过程中所有的东西，能不写死的都尽量不要写死，防止以后需求、数据、接口、逻辑等地方发生变动，有利于自己后期的修改；
4. 如何重构？
4.1：选择一个合适的架构
1>：之前的开发应该都是MVC，现在如果逻辑比较复杂，功能比较多的，可以使用MVP。
M指的是model，一般放javabean；
V指的是Activity、Fragment；
P指的是Presenter，一般都是把联网请求等一些数据处理放在P中；
然后在V中实现P，然后创建一个P的对象，在需要获取数据的地方就通过P的对象调用P中写好的方法，来返回对应数据就可以；
具体的可以参考 MVP - 自己在项目中的使用方式
4.2：技术的选定
1>：网络请求架构、缓存库、加载图片；
2>：ListView、RecyclerView等；
4.3：从小到大的重构
就是说不要一下子去大面积重构，逐个的每一个小的模块重构，并且保证可以运行；
5. 总结
其实就是一个原则：
1>：提取方法，去除重复的代码；
2>：抽取工具类，多个地方使用；
一定要避免在多个地方存在重复的代码，一定不要出现类似这样的问题，只要解决这个问题，其实就已经解决大部分问题。
