您已经了解应用程序维护是必要的。 The question now is different: how to put together a plan that works without turning into emergency chaos?
这段文字很简单。 It assumes that you lead a product or a team and need to move from theory to execution. Instead of philosophizing about the life cycle, let's look at what you actually put into the roadmap, the budget and the team's routine.
The central idea is simple: good maintenance is predictable maintenance. When it becomes routine, it costs less and is less scary.当它变得令人惊讶时，就会消耗团队和预算。
从可观察性开始
你无法保留你看不到的东西。 The first step of any plan is to install the eyes.
将崩溃报告添加到第一个版本、Firebase Crashlytics、Sentry 或同等版本的应用程序中。添加使用指标以了解哪些屏幕很重要以及用户在哪里遇到困难。 And set up alerts: you need to know something broke by notification, not by a one-star review in the store.
经验法则：如果您仅因用户投诉而遇到关键问题，那么您的[可观察性0]就失败了。这是整个计划中回报率最高的投资。
定义发布节奏
没有节奏的维护变成了集体努力。建立固定的更新节奏，每两周或每月一次对于大多数应用程序来说效果很好，将紧急修复与计划改进分开。
Use a clear versioning scheme (something like SemVer) so that everyone understands what each release means. Maintain a beta channel, with internal testers or volunteer users, before publishing to the entire base.这大大降低了错误更新同时影响所有人的风险。
The common mistake here is to launch only when there is a problem.当你更新只是为了救火时，每次发布都会紧张。 Regular cadence turns publishing into a banal routine.
有纪律地对待依赖关系
库和 SDK 是无声债务。他们工作直到停止工作，通常是在最糟糕的时刻。
保留应用程序使用的清单并定期检查。定期、小剂量地更新库，而不是累积两年的滞后才能立即解决。 Especially monitor payment, login and SDKs that require store compliance, they have strict deadlines.
特别注意漏洞。过时的依赖关系是一扇敞开的门，如果应用程序处理个人数据，则这直接属于[LGPD1´。 Preventive maintenance here is also a safety posture.
遵循商店要求
Apple and Google change the rules frequently and impose deadlines. New mandatory SDK versions, privacy requirements, changes in permissions, all of these can block new posts if you ignore them.
在团队日历上设置定期查看平台公告的时间。它并不迷人，但它是一种自适应维护，可以避免最糟糕的意外：发现您无法再发布紧急修复，因为应用程序不满足上个月过期的要求。
记录最小可行方案
完整的文档在实践中几乎不存在，但这没关系。 What you need is the minimum that allows someone else to take over the app without archaeology.
确保三件事：解释如何运行和发布项目的自述文件、最重要的架构决策的记录以及凭据和访问权限列表（当然，不暴露秘密）。 This basic package is what separates a sustainable app from an app held hostage by a single person.
精益清单
要完成计划，请验证以下几点：主动崩溃报告、配置的使用指标、定义的发布节奏、依赖项清单、商店审查日历、最少的文档，以及最重要的是批准的经常性预算。 If any of these are blank, that's where your next risk lies.
“我们稍后会解决它”的陷阱
该计划最大的敌人不是技术，而是文化。 It's the temptation to postpone maintenance in the name of delivering more features.
它可以工作一段时间。然后债务会收取利息：应用程序发展缓慢，每次更改都会破坏其他东西，并且团队花费更多的精力进行修复而不是构建。 The maintenance you didn't do doesn't disappear, it just becomes more expensive.
每个周期预留固定的维护容量。不是作为盈余，而是作为承诺。从长远来看，一个将一定时间用于产品健康的团队可以提供更多而不是更少。
结束
良好的维护计划并不是最复杂的。这就是球队每周都能维持的状态，无需英雄壮举。
从眼睛开始，创造节奏，控制依赖性并保护预算。其余的都是结果。维护良好的应用程序对用户来说是不可见的，它只是工作，更新后更新。
如果您想更深入地了解，我的博客上还有其他关于技术债务、[可观察性2] 和产品生命周期的文章。如果应用程序的维护已成为反复出现的危机根源，那么问题通常是流程问题，而不是代码问题，这是可以解决的。
另请阅读
- [移动应用程序维护：为什么要在启动之前进行规划3
- [移动应用程序的维护：避免失去控制的基本步骤4
- 【日常生活中的WebView：app的运维有哪些变化5
- [原生 Android 开发：快速启动应用程序6
- [日常生活中的应用程序备份：将复制变为安全的最佳实践7
- [应用程序中的缓存：良好实践快速指南（及其隐藏的错误）8