上週我有兩項工作內容是和產品維護有關的，剛好一個是 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 產品，在這個快速變化的時代，很難說不去做例行維護也能很好地運作下去。所以制定合理的維護計劃就變得十分有必要。
換句話說，在項目開始的時候，就要提前想想未來的維護計劃與大致成本。畢竟維護也是一個項目生命週期中不可缺少的極其重要的一部分。