前言

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

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

仓库地址：CloudDisk

CloudDisk示例

项目概述

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

1. 
   
2. 文件模块:用于管理用户云端文件系统。用户能够上传、下载、浏览文件。
   
3. 动态模块:类似微信朋友圈，用于可以在动态上分享信息及文件
   
4. 个人中心模块:用于管理用户个人信息
   

问题说明

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

1. 
   
2. 开发效率低，编译时间长，经常出现代码合并冲突
   
3. 代码质量差，经常修改出新问题
   
4. 市场响应慢，需要对齐各个模块进行整包发布
   

代码分析

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

包结构如下：

主要包说明：

主要类说明：

详细源码见CloudDisk

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

总结

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

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

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

系列链接

大纲