移动应用程序维护：避免失去控制的基本步骤

几乎每个应用程序的生命周期中都会有一个团队失去控制的时刻。这并不是突然发生的。这是渐进的。这里仓促修复，那里未更新的依赖项，推迟的架构决策，有一天弄乱应用程序变成了一种恐惧的练习。

本文是为那些想要避免这种情况的人而写的。这与维护理念或从头开始制定计划无关。它涉及按正确顺序排列的基本步骤，使产品能够多年来保持可控性。

一款经久不衰的应用程序与一款成为噩梦的应用程序之间的区别很少在于团队的才华。关键在于遵循这些步骤的纪律。

步骤 1：建立质量基线

在保留之前，您需要知道要保留什么。基线是所有新代码必须遵守的最低保证集。

在实践中：[自动化测试0涵盖关键流程、工具（linter、格式化程序）应用的代码标准以及阻止未通过的持续集成管道。第一天不一定是完美的。它需要存在并受到尊重。

没有这个基线，每次维护都是一场赌博。你修复了一件事，然后祈祷不要破坏另一件事。有了它，您将充满自信地改变。

第二步是组织。将关键错误与产品改进混在同一个队列中会导致混乱，紧急的事情总是会吞掉重要的事情。

保持轨道分开。紧急纠正的快速通道，以及快速投入生产的精益流程。以及规划的演进和预防性维护路径，它像任何功能一样包含在路线图中。

不这样做的风险是众所周知的：团队生活在紧急跑道上，永远不会到达预防跑道。技术债务不断累积，直到应用程序变得过于僵化而无法发展。

技术债务并不可耻，它是不可避免的。问题不在于拥有它，而在于它从不支付它。

这里最重要的一步是使付款持续且可见。每个周期留出固定的部分用于重构和更新。记录已知的债务，以便这是一个有意识的决定，而不是一个意外。首先攻击风险最高的部分：变化和破坏最多的代码。

经典的陷阱就是等待“大重构”。这种情况几乎永远不会发生，一旦发生，成本高昂且风险巨大。每次小额持续支付都胜过大笔努力。

可观察性是先决条件，但重要的一步不仅仅是拥有数据，而是利用数据来做出决定。

当然，要跟踪崩溃情况，但要更进一步：哪些屏幕集中使用，用户放弃哪些屏幕，哪些设备和系统版本对您的用户群真正重要。这些数据告诉您哪些地方需要投资维护，哪些地方不值得。

用同样的精力维护整个应用程序是浪费的。数据显示了价值在哪里以及风险在哪里。智能维护是有选择性的。

当“决定改变某些东西”和“能够安全发布”之间的时间开始增长时，这是失去控制的第一个症状。这个范围是温度计。如果它每个季度都上升，那么债务就会增加。将此视为一个指标，而不是一种感觉。

最容易被忽视的步骤不是技术性的。这是为了确保有人持续维护应用程序并有资金来维护应用程序。

当了解系统的人离开或不更新维护预算时，应用程序就会消亡。在公共部门，这种情况很普遍：合同涵盖了开发、管理变更，而公民服务应用程序仍然被遗弃在商店中，这恰恰损害了那些最依赖它的人。

连续性是有计划的。这意味着减少对英雄依赖的文档、提供多年维护的合同以及明确谁负责什么的责任。废弃的技术不是中立的，它会带来安全风险并破坏信任。

##反思：控制不是僵化

一个重要的警告。寻求控制并不意味着给产品加上流程。过多的官僚主义会扼杀速度，就像缺乏纪律会扼杀质量一样。

平衡在于流程足够轻松，让团队可以无怨无悔地遵循，但又足够坚定，防止走捷径成为常态。真正的控制是可以毫无恐惧地自由更改应用程序，而不是禁止更改它。

保持对应用程序的控制不是一个单一的行为，而是一系列按纪律重复的小决定。基线、单独的轨道、一点一点地偿还债务、指导数据、人员和预算得到保证。

孤立地看，这些步骤都不困难。困难的是坚持。正是这种持久性将持久的应用程序与默默腐烂的应用程序区分开来。

如果您的团队感觉他们正在失去对产品的控制，那么这就是解决方案的问题，并且几乎总是从上述步骤开始。我的博客上还有其他关于技术债务和软件质量的文本，这是一个可以引发良好对话的主题。