谈谈如何合理地为 App 与 Web 项目制定维护计划

上周我有两项工作内容是和产品维护有关的,刚好一个是 App 项目,一个是 Web 项目,每个项目都遇到了一点问题,于是借此我决定好好梳理一下如何为 App 与 Web 项目制定合理的维护计划,让项目能在持续良性运作与节省维护成本之间找到一个平衡。

App 项目的维护计划

我的 App 项目就是我发布于 2013 年的 macOS 桌面效率工具——Manico,目前它的最新版本是 2.8.1,更新于 2020 年 12 月,目前可以运行在 macOS 10.12 及以上更新的系统。

作为开发者,我自然希望我的产品可以尽可能多的运行在更多的设备与平台上,因此它支持 macOS 10.12,这个发布于 2016 年,整整五年前的操作系统版本。

然而过去几个月,大概是 macOS Big Sur 发布开始,我收到用户的反馈说有一些机制不工作了,比如自定义模式的拖拽。我不知道是因为操作系统升级导致旧功能不工作,还是因为使用了最新的 SDK 导致其不工作,总之这已经不奇怪了。早在 2018 年的时候,我就写过一篇文章《记一则 macOS App 开发糟糕的向后兼容问题》,几乎是一样表现形式(都是无法拖拽的问题),但引起问题的原因却已经不一样的。

当时我用 Workaround 解决问题后,让 Manico 重新了支持了比较早的 macOS 10.10,这次我决定,为了以后不再痛苦,不用兼容旧系统的思路去解决问题了。于是我彻底重构了 Manico 的表现层机制,用相对现代的 API,同时也付出相应的代价——将最小部署版本提高到了 macOS 10.14 版本。目前新版本还在内测中。

根据后台的用户操作系统统计数量,macOS 10.12 和 macOS 10.13 版本的用户大概只有 1% 了,我只能选择对这部分用户停止维护更新了,毕竟维护成本不允许,我甚至没有相应的环境去测试 Manico 是否在这两个版本的系统上 100% 工作。

如果我不提升最小版本支持,以后维护的代价会更大,这次就当是一个契机了。同时,以这次维护工作做为标准,我也确定了对 App 产品的维护计划,那就是,我的产品只要支持到 N-2 即可(N 代表当前的稳定版本),部分产品甚至可以 N-1。

也就是说,假如我的产品已经进入了维护期,不再去频繁加特性或修 Bug 了,我也要每年更新一个版本,去掉对最早一个操作系统版本的支持,升级一些过期的 API 等等。以适应未来的一些变化,而不是等到出现问题再去解决。

Web 产品的维护计划

说来也是巧,上周也碰巧维护了一个 2018 年做的 Web 外包项目,本来只是改一个小功能(见《使 Django 在搜索 Char 类型的 ArrayField 时不区分大小写》。后来我仔细看了下这个项目,好久没有升级基础环境了,特别是前端部分,干脆趁这次升级一下吧。

当时我把后端部分从 Django 2 升级到了 Django 3,非常轻松,3 分钟就完成了;前端用了 Nuxt,从 2.12 升级至 2.14,却在升级后编译失败了!一看原因,是 Vue 规则变严,不能修改 props,于是重新学习并用上了 .sync 和 $emit(‘update:property’) 方法…花了不少时间。

后来我分享到推特上去,有人说前端项目年更太久了,一般都月更。这确实不夸张——前端项目,常常几个月没照顾了,就会遇到编译通过不了,或者出现很多 vulnerabilities。对我这个偶尔维护一下 Web 项目的人来说,几乎是常态。

那么到底怎么给 Web 项目定维护计划呢?一个月可能会有点频繁,我决定定个 3~6 个月为周期的维护计划,至于是不是最合适的,只能去试试才知道了——总之,一年一次确实是太低了。

总结

无论是 App 产品还是 Web 产品,在这个快速变化的时代,很难说不去做例行维护也能很好地运作下去。所以制定合理的维护计划就变得十分有必要。

换句话说,在项目开始的时候,就要提前想想未来的维护计划与大致成本。毕竟维护也是一个项目生命周期中不可缺少的极其重要的一部分。

欢迎使用图拉鼎和他的团队开发的作品

效率控 - 聚合众多实用小工具

装机必备的高颜值工具箱,拥有超过 18 款工具,完成日常各类任务。支持 iPhone、iPad 和 macOS。

No Comment

Leave a Comment