DevEco Code实战:12天完成鸿蒙项目1000+文件重构迁移
说实话,听到“又要重构”这句话的时候,我自己心里都咯噔了一下。这是一个累计超过1000个文件的灵动小组件项目,距离上一次大规模迁移只隔了不到半年。但这一次不太一样,因为我们第一次把 DevEco Code 在重构场景里的能力完整地用了出来——从文件盘点、依赖分析到批量迁移、回归验证,12 天,1000+ 文件,整体搬完,线上无事故。这篇文章不聊虚的,就把我们这次第四次大重构从定方案到落地的全过程拆开讲,包括工具的具体用法和那些文档里不会写的坑。
如果你是鸿蒙应用开发者、负责老项目维护的客户端开发,或者正在纠结“要不要动老代码”这件事,这篇应该能给你一个比较完整的参考。
1. 为什么一个小组件项目需要经历四次重构
1.1 前三次重构到底在重构什么
很多人听到“第四次重构”的第一反应是“你们前面是不是在瞎搞”。这个质疑我完全理解,但实际情况是,每一次重构的原因都不一样,而且每次都跟当时的技术背景强相关。
我们这个项目最早是传统页面式的小组件应用,那会儿结构简单,几个页面直接堆在一起跑。第一次重构是为了把业务拆成可复用的组件,当时引入了组件化开发思路,把整个页面拆成了卡片、列表、弹窗等独立模块。这是第一次大规模改动,大概两百多个文件。
第二次重构的主要原因是开发语言切换。当时项目从旧的技术栈迁移到 ArkTS 加 ArkUI 的声明式开发模式,整个 UI 层的写法完全变了,从命令式改成状态驱动。那一次是真的痛苦,因为不只是改语法,是思维方式要转过来。组件怎么组织状态、数据流怎么走、父子组件怎么通信,全部重新捋了一遍,那次迁移的文件数大概在五六百左右。
第三次重构则比较局部,是为了适配新一代服务卡片框架。因为我们这个应用的核心就是“灵动小组件”,桌面卡片是灵魂,但当时新的卡片框架在生命周期和数据更新机制上跟旧的有很大差异,所以围绕卡片模块做了一次定向重构。那次只动了卡片相关的一百多个文件,影响面可控。
1.2 第四次重构的导火索:老模型、旧 API 与三方库三座大山
前三次重构虽然各自解决了当时的问题,但历史包袱是层层叠加的。到了第四次开始前,项目里其实已经积累了三座大山:
第一座是应用模型。项目还跑在旧的能力模型架构上,而新的模型架构已经成为主流,新开发的生态工具、系统能力、IDE 辅助功能都往新模型倾斜。旧的模型架构在部分新设备上的兼容性开始出现边际问题,比如部分多任务场景下的资源回收策略更激进,旧模型适配得并不好。我们抽样统计了近两个月的线上反馈,与进程重建、后台恢复相关的问题占比比上一模型架构的同类数据高出一截。
第二座是 API 版本。一年多前升级过一次 API,但当时只把编译时过不去的改了改,大量废弃接口还残留在代码里。这些接口短期内不会崩,但每次构建都会刷出一堆警告,而且官方对新设备的特性适配基本只走新接口链路,继续用旧接口等于主动放弃体验优化。
第三座依赖是一个核心三方库停止维护的消息。这个库承担着小组件内部数据缓存和状态同步的功能,但作者宣布不再维护,并且新版 API 存在不兼容变更。继续留在旧版本意味着后面遇到问题只能自己啃,而迁移到这个库的新版本又牵扯到调用的全面替换。
所以这次重构的本质是:趁着一个外部依赖逼宫的机会,把模型迁移、API 升级、历史债清理一次做完。
1.3 12 天这个目标是怎么定出来的
定“12 天”这个目标,来自一次很务实的倒排计算。
先把工作量拆开:项目里代码文件大概 1000+,去掉纯资源文件后,实际需要动代码的 .ets 和 .ts 文件大概在 800 个左右,剩余是一些配置、资源和测试文件。按以往经验,模型迁移加 API 升级这类工作,熟练的情况下人均每天能处理 30 到 40 个文件。我们团队两个人主攻,加上一个人做测试和外围支持,理论上的极限是每天 80 个文件上下。800 个文件分摊到 10 个工作日,每天差不多 80 个,刚好卡在耳熟能详的“加班可完成”区间。
当然,这只是理论值。我们预留了最后两天做全量回归和修修补补,真正用来迁移的时间其实只有 10 天。之所以敢接,是因为这次有 DevEco Code 帮我们兜底,后面会详细说它到底帮了多少。总之,12 天不是一个拍脑袋的数字,而是根据团队产能、文件规模、工具能力三方取交集的结果。