⭐此confluence系列纪念大三大四TCL实习时在confluence中学习到的一些额外的知识⭐
为什么要重构
接收新项目时，有时候会感觉项目很难理解，或者说代码很混乱。一接受的时候，不能盲目的认为别人的代码不好，需要认真的分析。因为每个人的代码风格都不一样，每个人的擅长的领域也不一样，所有有时候并不是说代码写的不好，也有可能是使用了一种新的技术，或者新的模式框架，需要我们去深入了解后，才能评估一个项目的好坏。
不能因为我们不熟悉或者不习惯就重构代码，而是应该提升自己的能力，需要学习更多更先进的技术来丰富自己。毕竟重构一个项目是非常耗时的。
哪些情况下是应该重构代码的呢?
- 框架混乱。这种混乱体现在很多方面, 比如:
- 文件路径随意。所有Java文件随意新建文件夹。
- mvp、mvvm模型随意使用。有些功能非常简单的界面，比如显示关于界面。像这种那么简单的界面，根本就需要使用复杂的模式，直接一个activity就可以搞定的。
- 复杂界面，功能和数据混合在一起。有些虽然使用一个mvp或者mvvm模型，但是还是能看到在activity上来处理数据的情况，或者说根本没有框架来分离，都在一个类里面实现了。
- 公用的功能没整合。比如一些功能是很多地方都会调用的，比如存储、访问API这种，哪里使用就哪里写是不方便管理的，这种应该整合到统一的模块中，方便管理和修改。
- 补丁多。修改bug有很多方法，有的时候为了修改方便，经常能看到直接打补丁的，而不是完善原来的方案的，这种补丁多了就容易出问题。
- 举个例子：在一个项目中，有一个接收广播会启动悬浮窗的功能，这种功能因为并没有把应用提升到前台来展示，也就是没启动activity的，所有进程的优先级在系统中是很低的。此时是很容易被系统杀死的，所以为了解决这个问题，就需要提升进程的优先级。
- 正常的修改，肯定是在接受到广播之后，启用进程优先级更高的控件来提升优先级的，比如前台服务。但是因为悬浮窗显示这块比较麻烦，就看到一种打补丁的方式，就是在启动悬浮窗的同时，再起一个空的前台服务。
- 以上这种补丁方式，都是有隐患的，如果整个应用里面这种补丁比较多的话呢，整体性能和稳定性是很差的，经常有一个奇奇怪怪的bug。
重构哪些部分
重构就是在之前的基础上进行部分的优化, 所以优化哪些部分就是关键。在我看来, UI或者算法之类的, 没有很严重的问题, 是没必要去动的, UI这部分大同小异, 就算重构, 也是UI出图, 代码本身改动有限。算法是核心, 除非你是专业人才, 否则不一定比之前的做的好。
重构的核心我觉得不是创作, 而是整合。整个应用的功能都是开发好的, 只不过还有一些瑕疵, 所以我们只需要把所有的功能重新梳理, 并整合好就可以。
可以从以下部分入手:
- 框架设计: 框架说大点就是整个APP的结构, 说小点呢, 就是activity的模型。
- APP结构的部分呢, 多进程的一定要代码分离。同一进程的需要把基础组件, UI界面和功能模块进行统一管理。最好就是文件夹名称让人一看就明白里面放的是什么。
- activity模型部分, 我建议是根据实际情况和个人喜好来规划, 功能简单的不建议使用复杂的模型, 功能复杂的建议选择自己熟悉的模型来操作。比如在mvp模型中, 我就会采用UI界面在activity处理, 数据操作在presenter中处理, 还会再定义一个接口层方便ui-数据之间来相互调用。
- 比如一个在一个功能很复杂的界面中, 所有的数据和UI交互都整合在一个activity里面, 我想这样的类是很难维护的, 因为代码复杂。这个时候, 对整个activity进行重构就很有必要, 把其中的数据处理和UI进行分离, 统一的模块也需要功能分类, 也就是下一个部分了。
- 功能分类: 什么样的功能需要提炼出来, 作为一个功能模块呢
- 其实很简单, 就是哪些不依赖界面, 不依赖acitivity数据的, 或者是那种通用的方法都是可以提出来作为一个统一的功能模块。这样就能减轻activity的代码量, 只需要一个调用接口就可以实现功能了。
重构的误区
- 为了重构而重构
- 需要理解哪些部分重构, 在项目中也遇到过, 明明很简单的东西, 为了体现代码的能力, 使用了很复杂的控件或者框架, 我觉得代码首先是性能, 其次就是可阅读性, 在性能相差不大的情况下, 选择简单易懂的才是最好的, 有利用公司内部代码的共享和共同维护。
- 数据和界面的完全分离
- 整体思路应该是分离的, 但是很多情况需要根据使用场景来判断, 不能盲目的所有的照搬照做。比如在视频通话界面, 成员数据和成员界面之间就需要进行同一模块来处理, 为什么要放在一起呢, 因为成员界面是需要改变的, 如果同一界面的移动, 小窗口的布局切换。
这些方案都是界面和数据一起移动的, 在这种情况, 不是一味的数据改变来刷新界面, 还需要界面改变来查找数据。这种情况建议就是一个成员的界面和数据做成一个模块来处理。