前言

上一篇移动应用遗留系统重构（2）- 架构篇，我们介绍了业内的优秀架构实践以及CloudDisk团队根据业务情况设计的分层架构。

这一篇我们将介绍一个浓缩版的示例，示例中我们设计了一些常见的异常依赖，后续的重构篇我们也将基于这个示例进行操作演示。为了简化代码及对业务上下文的理解，示例中的部分实现都是空实现，重点体现异常的耦合依赖。

仓库地址：CloudDisk

CloudDisk示例

项目概述

CloudDisk是一个类似于Google Drive的云存储应用。该应用主要拥有3大核心业务模块。

1. 文件模块:用于管理用户云端文件系统。用户能够上传、下载、浏览文件。

2. 动态模块:类似微信朋友圈，用于可以在动态上分享信息及文件

3. 个人中心模块:用于管理用户个人信息

问题说明

该项目已经维护超过10年以上，目前有用开发人员100+。代码在一个大单体模块中，约30w行左右，编译时间5分钟以上。团队目前主要面临几个问题。

1. 开发效率低，编译时间长，经常出现代码合并冲突

2. 代码质量差，经常修改出新问题

3. 市场响应慢，需要对齐各个模块进行整包发布

代码分析

代码在一个Module中，且在一个Git仓中管理。采用"MVC"结构，按功能进行划分Package。

包结构如下：

主要包说明：

包名	功能说明
adapter	ViewPager RecycleView等适配器类
callback	接口回调
controller	主要的业务逻辑
model	数据模型
ui	Activity、Fragment相关界面
util	公用工具类

主要类说明：

类名	功能说明
MainActivity	应用主界面，用于加载显示各个模块的Fragment
CallBack	网络接口操作回调
DynamicController	动态模块主要业务逻辑，包含发布及获取列表
FileController	文件模块主要业务逻辑，主要包含上传、下载、获取文件列表
UserController	用户模块主要业务逻辑，主要包含登录，获取用户信息
HttpUtils	网络请求，用于发送get及post请求
LogUtils	主要用于进行日志记录

 

详细源码见CloudDisk：https://github.com/junbin1011/CloudDisk

为了简化业务上下文理解，代码都是空实现，只体现模块的异常依赖，后续的MV*重构篇会持续补充常见坏味道示例代码。

总结

CloudDisk在业务最初发展的时候，采用了单一Module及简单“MVC”架构很好的支持了业务的发展，但随着业务的演化及人员膨胀，这样的模式已经很难高效的支持业务及团队的发展。

前面我们已经分享了“理想”（未来的架构设计）与“现实”（目前的代码现状），接下来在我们开始动手进行重构时，我们首先得知道往理想的设计架构演化，中间存在多少问题。一方面作为开始重构的输入，另外一方面我们有数据指标，也能评估工作量及衡量进度。

下一篇，我们将给大家分享移动应用遗留系统重构（4）- 分析篇，介绍常用的分析工具及框架，并对CloudDisk团队目前的代码进行分析。

系列链接

移动应用遗留系统重构（1）- 开篇

移动应用遗留系统重构（2）-架构篇

标签：重构,示例,代码,业务,CloudDisk,模块,遗留
来源： https://blog.csdn.net/ruanchengshen/article/details/115653334