重构 Android

移动应用遗留系统重构（5）- 重构方法篇

前言

上一篇

移动应用遗留系统重构（4）-分析篇我们根据CloudDisk未来的架构，借助ArchUnit进行架构测试守护以及Intellij的Dependendencies分析出了按照未来的架构设计需要解决的异常依赖。

这一篇开始我们将分享进行依赖解除的重构流程、方法以及常用的工具使用。

重构流程

1.识别一个内聚的包

2.解除该包的异常依赖

3.移动该包对应的代码及资源到新的模块

4.包解耦验收

1.识别内聚的包

对于移动应用通常我们可以通过产品的业务划分进行领域的识别划分。例如CloudDisk这个产品的相对还是比较清晰，业务上主要分为文件、动态及个人中心。

对于部分遗留系统来说，旧代码可能散落在不同的包下，或者原先的代码组织方式是以功能划分，而非业务划分。就像CloudDisk的代码一样，第一步我们得先把相关的业务代码组织到同一包下，这个阶段我们可以先不管是否存在异常依赖，因为只有先组织到一个内聚的包下才方便我们进行依赖分析及代码重构。

2.解除异常依赖

这里我们将介绍几种通用的依赖解除手法。包含下沉、接口提取、路由跳转。

后续的演示篇会通过视频进行具体的操作演示

依赖解除手法	使用场景
下沉	原本类功能属于Library或者Platform的，直接下沉。例如LogUtil 或 DateUtil等
接口提取	适用于Bundle间有数据或者行为依赖。例如某个BundleA中的classA需要触发BundleB的某个业务行为
路由跳转	适用于UI页面间跳转。例如某个BundleA中的Activity1，需要跳转到BundleB的Activity2

重构手法：

类下沉

将具体类移动到适当的 Lib 模块中
在调用模块增加对该 Lib 的依赖

接口提取

在适当的公用模块中创建空的接口
将调用具体页面类的跳转代码块所在的包中建立新的实现类实现该接口
(自动)将调用代码块通过 Extract method 提取成新方法

如已经是独立方法跳过此步

(自动)在原调用逻辑所属的类中增加实现类的成员变量作为delegate

需要预留 Inject 接口，建议采用 Constructor Inject，静态成员提供setter

(自动)将新方法调用转移到delegate中

如果是静态方法先通过 Change Method Signature 将 delegate 作为参数传给该方法

(自动)将新方法 Pull up 到接口中
(自动)将实现类移动到壳程序中
在壳程序中实现实现类的Inject

路由跳转

在跳转类定义对应的映射Path
在调用处使用对应的path进行跳转

3.移动代码及资源

当包的异常依赖全部解耦完后，就可以直接进行移动了。这里我们分享2中常用的代码移动方式。

Move

这种方式大家应该比较常用，选择一个File或者Directory,按下F6选择希望移动后的目录则可。

但是这种方式会存在一个问题，就是被移动的类如果依赖了其他的类或者资源，移动后会出现依赖异常。

适用场景：移动的File或Directory没有其他的依赖

Modularize

Modularize能够分析出移动的File存在的相关依赖，并一起关联移动，很好解决Move的痛点，非常适用于跨Module的移动。

选择移动的Module后点击Preview。

这里注意，有一些划线的文件，那是因为这个文件同时被多处引用，如果跟随一起移动，那么其他的地方会报错。所以我们需要将划线的文件先移动至公用的合适位置。待Preview没有任何的文件划线时，就可以进行移动。

4.包解耦验收

所有模块编译通过
所有新增模块符合模块依赖规则
通过架构守护测试

总结

这一篇我们分享了进行依赖解除的重构流程，主要为4个操作步骤，识别内聚包、解除依赖、移动、验收。同时也介绍了Intellij中非常好用的Modularize功能。接下来我们就可以开始动手进行代码重构，但此时我们又面临着另外一个问题，也是很多同学在做重构时经常担心的一个问题。重构时如何保证功能的正确性，不会修改出新问题。

下一篇移动应用遗留系统重构（6）- 测试篇，我们将分享对于单体移动应用遗留系统，如何制定测试策略及有效补充自动化测试，更好为重构保驾护航。