移动应用的持续维护：更新、崩溃、发布

应用在发布日停止编写，开始维持生命。平台每年发布一个新系统版本，商店规则变化，库获得安全修复，而这些都不会等到你路线图中的空闲周。六个月没有人触碰的应用很少看起来破损——它只是停止在干净的机器上构建，开始在最新设备上崩溃，并在商店中滑落，因为最近的评论都是关于冻结和数据丢失的。每年支付一次救援操作的费用远高于持续保持项目状态的费用，而救援总是在最糟糕的时刻到来。

我每次都以同样的方式开始：诚实地审视实际情况。我在干净的机器上从头开始构建项目，阅读它是如何组装的，列出多年未变的依赖项，标记代码中的脆弱点，并查看来自真实设备的崩溃报告。这给你一个简短的书面裁决——现在必须修复的内容、可以等待的内容，以及每个延迟可能的成本。之后，工作以周期进行：更新依赖项并添加对新操作系统版本的支持，追踪崩溃的原因并修复它们，减少冷启动时间和电池消耗，进行你要求的小改动，然后准备、签署并发布下一个版本。我还阅读那些抱怨技术而非产品的评论——崩溃、冻结、消失的数据。这些评论几乎总是指向一个特定的缺陷，它们是我所知道的最便宜的工作来源。

在我们开始之前，我大声说出三件事，以免后面让人失望。应用商店的审核时间不是我能控制的：我准备发布，回答每一个异议，并确保其发布，但没有人能承诺确切的发布日期，我也不会假装可以。崩溃报告是匿名收集的，只有在用户同意的情况下——屏幕内容、输入的文本和个人数据从不发送，并且在缺乏同意的情况下，我只能使用可用的信息。放弃对旧系统版本的支持是根据仍在使用它的用户比例达成的，而不是基于对我方便的考虑：我提供数据，你做决定。

维护涵盖的内容：
— 当前项目及其构建状态的审查，附带书面裁决；
— 依赖项更新和对新操作系统版本的支持；
— 来自设备报告的崩溃分类、根本原因分析和修复；
— 更快的启动、更低的电池和流量消耗；
— 根据你的请求进行的小改进和更改；
— 发布准备和通过商店审核的支持；
— 处理报告技术问题的评论；
— 知识转移给你的团队和季度发布计划。