谈谈如何合理地为 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 产品，在这个快速变化的时代，很难说不去做例行维护也能很好地运作下去。所以制定合理的维护计划就变得十分有必要。

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