【译文】不是所有的 bug 都值得修复的

喜欢ヅ旅行 2022-04-11 02:03 231阅读 0赞

原文作者：KRISTINE PINEDO

译者：白乐航

欢迎访问[网易云社区][Link 1]，了解更多网易技术产品运营经验。

作为软件开发者，您只需要为客户编写和交付出色的产品和功能。 但您也知道软件开发并不总是那么容易，因为进行迭代时候可能会引入bug。 毕竟，“如果调试是删除软件bug的过程，那么编程肯定就是将bug放入去的过程”，正如Edsger Dijkstra（译者注：著名荷兰计算机科学家，我们熟知有向图最短路径算法--迪杰斯特拉算法就是他的），所说。

因为这些问题将会影响你的客户，所以你可能会感到修复应用程序中的每个bug的强大动力。

但这是一个坏主意。

## 应用程序稳定性和零bug ##

不存在零bug的应用程序，因此制定有效处理策略是至关重要。这就是为什么应用程序稳定性指标对于敏捷团队如此重要。稳定性可以定义为给定版本的应用程序交互中每个功能正常的百分比。它是通过跟踪应用程序用户遇到的崩溃(未处理的bug)的百分比来计算的。

![20181204094820bb615ae0-e5f0-4613-af1b-af20f0f3dd07.png][]

考虑可用性对于了解稳定性指标是有帮助的。 你可能已经熟悉“五个九”的可用性（译者注：即99.999%高可用性），并且你也已经知道不要设目标为100%，即使它看起来像是一个合乎情理可能完成的目标。 超过某一程度时，你将会遇到回报递减，因为高可用性目标是昂贵的而且不总是能够带来实实在在的好处。 Sean Hull谈到了为什么高可用性的评价过高了。

事实上，以五个九的标准维持高可用性会花费很多钱。

关于稳定性的还有个类似的情况 —— 在某种情况下，由于构建新功能的机会成本很高，所以修复bug成本很高。所以你制定目标时要考虑可行性，它不应该是100％。

这就是原因。

### 敏捷统治世界 ###

敏捷开发现在主导着软件开发过程，并且已经超过瀑布模型，成为构建和部署软件的实际上的方法。在VersionOne发布的2018年敏捷状态报告中，97%的受访者表示他们在他们的组织中实践过敏捷开发。敏捷团队正在以前所未有的速度构建和交付软件。许多开发者实行持续部署，这使他们能够在每周、通常是每天的基础上快速迭代他们的工作。快速的发布周期使得在发布后修复问题变得很容易，因此在发布前修复每个bug不再是绝对重要的。然而，在敏捷开发中，传统的QA和测试的可用时间也更少，这增加了引入bug的风险。

那么，如何平衡快节奏的开发和bug呢?应用程序的稳定性需要一个反馈循环，可以使用稳定性监视工具进行跟踪。

### 用户可以选择 ###

客户可以选择使用他们使用的应用程序，因此，如果您想让客户随时随地提供可靠，高质量的应用体验至关重要。 这是一个常见的例子，但我们都经历过。你需要参加会议，就打开骑行应用程序中的一个。 令人讨厌的是，优步(Uber )不适合你并且看起来还崩溃了，但你仍然需要参加你的会议，所以你打开Lyft来使自己按时到达。 因为这可以很容易地发生，你可能会觉得有必要修复每一个突然出现的bug。 但关于这些bug [Jeff Atwood’s][Jeff Atwood_s] 提出了很重要的问题，

“你如何区分用户可能遇到的bug，以及用户可能永远不会看到的bug？”

这是一个需要考虑的重要问题，你可以打赌你的竞争对手也会试图自己解决这个问题，这样他们就可以通过快速发布新功能来继续改进他们的产品。

### 客户端的西部蛮荒 ###

并不是所有的bug都是一样的，在客户端应用程序中尤其如此。

JavaScript比以往任何时候都流行，超过69%的开发人员使用JavaScript，使其成为最常用的编程语言。JavaScript的一个难点是，一旦部署到浏览器中，应用程序运行的条件可能会有很大的不同。考虑到大量的不同的浏览器、版本、扩展和其他可能影响应用程序稳定性的因素，几乎不可能考虑所有可能的场景。而且由于存在如此多的差异，大量的稳定性问题将成为不会影响大多数用户的边缘问题。例如，由于非常低的使用率和奇怪的怪癖，调查Internet Explorer 6（译者注：非常老的浏览器，2001发布2014微软停止维护）引起的bug可能毫无意义。

移动应用程序为开发人员带来了类似的挑战。Android设备中的设备种类是非常多的。你知道2015年市场上有超过24000种不同的安卓设备吗?

![20181204094848dfdec7ff-1c52-4790-bf42-b9b25e8455e0.png][]

部署到移动设备可能更加不可预测，因为设备和设置可能会有很大的不同，并在与应用程序交互时导致问题。像JavaScript一样，很多突然出现的bug都是边缘情况，只会影响少数罕见的手机。

花几个小时修复一个只影响少数用户的bug是不值得的。

### 特性或bug?选择一个。 ###

正如Eric Sink所写的，“关于软件质量的决策可能是艰难而微妙的，当我们做出这些决策需要非常明智。有时一个“bug”不应该被修复。那么，有什么更好的方法来看待bug呢?

将稳定性转化为团队的KPI。

选择一个可以实现的，有意义的目标，你的团队可以为此负责。稳定性指标可以帮助你决策关于工程资源的数据驱动。当你计划短期加速进度时，你应该分配时间来解决问题，还是应该在产品路线图上全速前进?应用程序稳定性帮助你做出决定。

值得重新检查你的警报堆积，以确保你有必要的反馈循环，或者是否有改进策略的空间。我留给你们几个重要的问题要考虑:

\-你的团队是否考虑过应用程序的稳定性?

\-你目前如何选择修复bug和构建新特性?

\-你的团队如何跟踪和优先处理bug修复?

原文：https://blog.bugsnag.com/application-stability-monitoring/

[免费领取验证码、内容安全、短信发送、直播点播体验包及云服务器等套餐][Link 2]

更多网易技术、产品、运营经验分享请[点击][Link 1]。

相关文章：  
【推荐】 [云计算交互设计师的正确出装姿势][Link 3]  
【推荐】 [浅谈 kubernetes service 那些事 （下篇）][kubernetes service _]

[Link 1]: https://sq.163yun.com/blog?tag=M_tg_880_72
[20181204094820bb615ae0-e5f0-4613-af1b-af20f0f3dd07.png]: /images/20220411/62cca30bd50b4546a8e7dde331a4317c.png
[Jeff Atwood_s]: https://blog.codinghorror.com/not-all-bugs-are-worth-fixing/
[20181204094848dfdec7ff-1c52-4790-bf42-b9b25e8455e0.png]: /images/20220411/a814e1dc995b46878a2db83bb1678731.png
[Link 2]: https://www.163yun.com/free?tag=M_tg_880_72
[Link 3]: https://www.jianshu.com/p/c73201be3076
[kubernetes service _]: https://juejin.im/post/5bf64ce051882512d444e0cd