移动应用遗留系统重构(18)- 总结篇

回顾

本篇是移动应用遗留系统重构的最后一篇,伴随着CloudDisk团队系统的不断演化,解决团队中实际的问题,我们已经持续更新了18篇。内容主要包括架构设计与分析、安全重构、基础生态设施、流水线、编译构建等。

心得

在实际的项目中,除了技术相关外,要成功落地,协作与沟通非常重要。下面我们分析几个在过程中需要注意的关键点。

向上沟通,得到支持

这种大型重构的投入成本和风险比较大,所以一定要得到上级的领导的同意,才能更加有保证的落地。通常很多产品经理或者领导不愿意投入,是因为这个事从用户角度来说,其实很难直接度量价值,更多只能衡量过程的指标。但其实对于我们自己来说,我们也需要有度量的指标来衡量重构的效果。所以这里我们其实可以从2方面角度来切入进行衡量,效率和质量。这里提供一些度量唯独的参考。

效率

  1. 减少编译时间

这个是最直观的数据,例如项目从整体编译10分钟到1分钟,1天1个开发同学编译5次,就是节省45分钟,100个开发同学就能减少7.5小时。

  1. 降低沟通协作

组件化后模块间基于接口契约,减少耦合。同时单个组件模块支持独立调试验证,测试同学可以提前介入验证。

  1. 缩短测试独占周期

我们的每次重构都会及时补充有效的自动化验收测试,和测试同学对齐策略后,可缩短手工的回归测试时间。

质量

  1. 降低模块的耦合度

分析阶段我们得到项目整体的耦合点数量,通过各个模块不断的解偶,耦合点数量应该呈下降趋势。

  1. 降低代码重复率

平台及公共库的抽取,封装复用,有效降低代码重复度。

  1. 降低代码圈复杂度

随着上帝类被分解重构为MVP或MVVM,类及方法的长度得到有效的降低。

对齐需求,小步前进

在重构的过程中,我们的需求是同步进行的。所以我们应该拉通版本规划一起制定重构策略。

  1. 即将下线的功能模块,不用投入做重构改造
  2. 核心稳定的功能模块,重点投入
  3. 优先挑选近期少改动的功能模块入手,避免冲突
  4. 小步安全重构,每天频繁同步及合入
  5. 涉及业务代码,建议进行结对编程

以始为终,以终为始

制定度量目标,阶段性进行总结。过程中将优秀实践总结固化到团队中,将持续的重构纳入到日常的开发工作中。以解决团队遇到的实际问题出发,如果你的团队只有3-5人,业务规模量小,那单体的系统未必效率更低,架构的演化是解决产品及团队的问题。

展望

对于CloudDisk团队来说,这次的重构之旅不是个终点,而是起点。随着业务及市场的发展,团队面临新的诉求,那就是动态更新及跨平台

  1. 随着业务发展及独立规划,各个业务bundle需要能够自己规划版本进行动态发布,不需要跟着整包一起发布
  2. 随着移动市场的发展,为解决各个系统的进度及开发成本,平台需要支持跨平台容器,而且除了Android、IOS 2大操作系统,还需要移植到鸿蒙平台。同时能够支持PC版本更优。

CloudDisk示例代码

CloudDisk

系列链接

移动应用遗留系统重构(1)- 开篇

移动应用遗留系统重构(2)-架构篇

移动应用遗留系统重构(3)-示例篇

移动应用遗留系统重构(4)-分析篇

移动应用遗留系统重构(5)- 重构方法篇

移动应用遗留系统重构(6)- 测试篇

移动应用遗留系统重构(7)- 解耦重构演示篇(一)+视频演示

移动应用遗留系统重构(8)- 依赖注入篇

移动应用遗留系统重构(9)- 路由篇

移动应用遗留系统重构(10)- 解耦重构演示篇(二)

移动应用遗留系统重构(11)- 制品管理篇

移动应用遗留系统重构(12)- 编译调试篇

移动应用遗留系统重构(13)- 编译调试篇

移动应用遗留系统重构(13)- 编译调试篇

移动应用遗留系统重构(14)- Kotlin+MVVM重构示例篇

移动应用遗留系统重构(15)- 数据库重构示例篇

移动应用遗留系统重构(16)- Gradle依赖管理篇

移动应用遗留系统重构(17)-流水线设计篇

大纲

关于