移动应用程序维护：为什么要在启动前进行计划

大多数应用程序在启动后就会死掉。并不是因为这个想法不好，而是因为有人将“上线”视为终点线。聚会举行，团队庆祝，预算最终确定，六个月后，该应用程序充满了错误，在新版本的操作系统上崩溃并失去了用户，而没有人明白原因。

应用程序维护不是技术细节。它是生命周期的一部分，决定产品是否会多年产生价值或成为隐性成本。几乎没有人在开始之前就计划好这一点。

那些从未构建过软件的人倾向于想象一个完成的应用程序就像一座交付的建筑：你剪掉胶带，它就留在那里，继续工作。现实更像是一个花园。如果你停止照顾它，它就不会保持原样，它会退化。

什么是应用程序维护？

维护不仅仅是“修复损坏的部分”。这只是四种类型中的一种，从长远来看可能是最不重要的。

纠正维护可纠正缺陷。 自适应 在环境发生变化、新的 iOS 和 Android 版本、第三方 API 更改、新的设备型号时保持应用程序运行。完美改进了实际使用中已经存在的东西。 预防性可降低未来风险：重构、更新库、减少技术债务。

典型的管理错误是只为纠正措施提供资金。结果是一个不断灭火但永远不会发展的应用程序。当您了解适应性和预防性是强制性的而不是可选的时，有关预算的讨论就会完全改变。

移动应用程序并不是单独存在的。它依赖于未经许可而更改的外部依赖项。

Apple 和 Google 每年都会发布其系统的新版本，并定期要求已发布的应用程序满足更新的 SDK、隐私和权限要求。如果您不更新，商店将停止接受新版本，并且在极端情况下会删除该应用程序。

添加外部依赖项：支付网关、登录提供商、地图服务、分析 SDK。它们中的每一个都在发展、废弃端点并改变规则。您的应用程序可以完美编码，但仍然会因为供应商更改了某些内容而崩溃。

这就是为什么适应性维护是不可避免的。你无法控制你行走的地面。

这是本文的中心思想。维护应用程序的质量和成本早在第一个用户出现之前就已确定。它们是一开始做出的决定的结果。

干净的架构、自动化测试、有意识地选择依赖项、从一开始就具有可观察性，所有这一切实际上都是对未来廉价维护的投资。反之亦然：一开始的仓促和捷径会变成收取多年利息的技术债务。

当有人向我提供应用程序的时间表并且没有说明启动后会发生什么时，我已经知道会发生什么。产品将诞生，然后悄然开始腐烂。

从项目设计的三个方面进行思考。首先，连续性：谁将维护该应用程序，具有什么容量以及什么经常性预算。其次，[可观察性1：在用户抱怨、崩溃报告、日志、使用指标之前，你如何知道某些东西出了问题。第三，技术可预测性：最少的文档、代码标准和测试，让其他人无需考古就能理解系统。

这些方面在规划时都不昂贵。以后即兴创作时，它们都非常昂贵。

在公共部门，这一点尤其敏感。雇用公民服务应用程序、安排预约、发布文件、报告的市政厅需要明白，它是在做出持续的承诺，而不是购买封闭的产品。

这种重复的模式令人悲伤：合同涵盖了开发、管理变更、维护预算没有更新，两年后该应用程序被放弃在商店中并获得一星评价。公民失去了，他们对数字政府的信任也随之消失。

在这种情况下，维护是公共服务的连续性。它需要在合同、多年预算和明确的责任中予以规定。将其视为偶尔的开支注定会失败。

第一个是将维护与不活动混为一谈。 “应用程序已经准备好了，你不需要碰它。”不存在停止的应用程序这样的事情，只有一个应用程序已停止被处理并且正在慢慢降级。

第二是不去衡量任何东西。如果没有崩溃报告和使用指标，您就是盲目的。当损坏已经造成时，通过店内评估发现问题。

三是将依赖视为永恒。过时的库会积累安全漏洞，从 [LGPD2´ 的角度来看，当涉及个人数据时，这是一个直接风险。预防性维护也与安全有关。

启动应用程序是其生命周期的开始，而不是项目的结束。幸存下来的应用程序并不是发布当天最漂亮的应用程序，而是旨在维护的应用程序。

从一开始就规划维护并不悲观。这是成熟。它认识到软件是动态的，并且照顾好你所构建的东西与构建它一样有价值。

如果您打算投资某个应用程序并且该计划在发布时就结束了，那么在订阅之前值得重新考虑。我的博客上还有关于数字产品生命周期和技术债务的其他文本，如果这是您组织中的特定问题，那么这种对话是有回报的。