测量小程序应用程序稳定性以减少技术债务

在快速发展的小程序开发软件和应用程序开发世界中，有一个现实是正确的：错误是不可避免的。即使您尝试尽可能减少错误，但最终还是会忽略其中一些错误，以使您的应用或新功能更快地投放市场。  

这个概念称为技术债务。每个人都拥有它；对于开发人员来说，这是生活的事实，他们了解日常工作如何导致该问题。每当产品团队向市场推出新功能或想要进行增量代码更改以使客户满意时，技术债务就会增加。当软件框架和语言没有及时升级时，情况也是如此，因为高管们不想减慢开发速度。

尽管听起来有问题，但技术债务并不总是坏的。在某些方面，这就像金融债务。您可能需要短期承担债务，但如果长期让债务搁置，则会导致重大问题–软件性能较弱。随着技术负担的增加，它会减慢代码库中新产品工作的创建和维护。

发生这种情况时，会对小程序开发人员造成重大的情感“拖累”。为什么？因为开发人员经常感到缺乏能力来解释技术债务的影响，并发现很难获得更广泛的组织支持来解决它。这造成了一个恶性循环，导致挫败感加剧，生产力损失和项目脱离。

通常，技术债务被视为“工程问题”，阻碍了赚钱活动，例如建立新功能和取悦客户。开发人员很少能成功赢得部门外部的拥护者，因为他们缺乏正确的工具来证明技术债务造成的问题。 

专注于测量稳定性

通过将稳定性概念引入对话，开发人员可以提高意识并扩大有关技术债务的对话。组织必须在提供可靠的产品路线图和维护健康且不断发展的代码库之间寻求平衡。如果工程，应用和产品团队没有一种方法来公开，定期地讨论并就技术债务的影响达成协议，那么就不可能实现这种平衡。

由于技术债务是代码库中的可衡量的阻力，因此影响很容易看到。而且，通过衡量技术债务，您可以确定软件的稳定性。 

评估稳定性就像基础架构和运营团队如何依靠“五个九”来跟踪可用性，衡量正常运行时间并遵守SLA。可以通过使用实时错误率和会话数据来确定每个版本中成功的用户交互百分比来计算软件稳定性。该百分比用作稳定性分数，表明每个软件版本的稳定性。 

简而言之，当客户享受与应用程序的无错交互时，稳定性得分很高。如果错误导致中断或崩溃，则稳定性得分会很低。 

从技术债务到业务价值

客户对无法正常运行的软件没有耐心。实际上，有80％的人只会在继续进行之前重试一次或两次应用程序。借助稳定性评分可以直接洞悉错误和用户体验的实际影响，组织可以更好地了解更少的技术债务会如何转化为更强的业务价值。 

更重要的是，可测量的结果消除了仅由工程团队承担的技术债务负担。现在，它已成为整个组织可以定期查看和处理的指标。 

当跨职能团队以相同的语言衡量和沟通技术债务时，他们可以确定何时以及如何解决技术债务。这是建立您的组织方法时应问的一些问题：

•我们的目标稳定性是什么？ 

•我们每个版本的稳定性得分是否都超过了目标？

•如果有任何稳定性得分低于我们的目标，那么最适合首先修复哪些错误？

•我们可以为将来的版本切实设置哪些目标稳定性分数？我们是先解决影响关键客户的错误，还是专注于影响许多客户的错误？

•多少个错误就是太多的错误？

使用稳定性评分时，这些问题将成为讨论重点，而不是沮丧的根源。通过重新定义对话，团队不再从为烦恼的客户哀叹（下行保护），而转向集中精力更快地开发功能并消除技术债务的拖累（上行产生）。采用稳定性作为KPI的团队可以通过稳定性评分将技术债务纳入工程团队的目标，从而从上到下建立问责制。 

错误是创新的结果。要继续前进，您需要创建错误（以及许多错误）。但是您还需要适当的方法来及时解决错误的存在。 

团队中的每个人都可以根据业务需求，产品需求和客户需求来积累技术能力。