程序员，你还在加班写 Bug 吗？

并非所有的bug都值得改，也可以不改。

作为软件开发者，最想做的事情就是给客户建立并发布最完美的产品和功能。但你也知道，软件开发并不容易，每次修改肯定都会引入bug。毕竟，就像迪杰斯特拉说过的那样，“如果说调试是去除软件bug的过程，那么编程就是引入bug的过程。”

由于这些bug会影响到客户，你可能会强烈地希望改正应用程序中的每个bug。

而这几乎是不可能做好的。

应用程序稳定性和零bug

没有完全无bug的应用程序，因此拥有一个有效处理bug的策略是非常重要的。因此，应用程序稳定性目标对于敏捷团队十分重要。稳定性可以定义为在特定的发布中，每次交互会话中的成功的应用程序交互的百分比。这个值就是用户使用应用程序时遇到的崩溃（未处理的错误）的百分比。

对可用性的思考有助于理解稳定性目标。你可能已经很熟悉“五个九”的可用性（https://en.wikipedia.org/wiki/High_availability#%22Nines%22），而且你也知道即使100%的目标似乎可以达到，也没必要去追求。超过某个点只有，高可用性带来的回报几乎降为零，而成本却非常高，使得高可用性不再有收益。Sean Hull在《为何高可用性被过誉了》（https://www.iheavy.com/2012/04/01/the-myth-of-five-nines-why-high-availability-is-overrated/）一文中谈过这一点。

“实际上，维持五个九的标准的高可用性就要花掉很多钱。”

稳定性也很相似。超过某个点之后，由于构建新特性的高昂机会成本，继续修改bug的代价变得非常高。因此，你需要像可用性目标那样确定稳定性的目标，而且这个目标不应该是100%。

原因如下……

敏捷统治世界

敏捷开发已经成为最主流的软件开发过程，已经取代了瀑布式开发，成为构筑软件的事实标准。在VersionOne发布的2018年敏捷开发报告（https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report）指出，97%的受访者都说他们的组织在使用敏捷开发。敏捷团队能以更快的速度构建和发布软件。许多实践，如持续部署，能让开发者能更快速地进行迭代，比如每周迭代，甚至每天迭代一次。更快的发布周期使得上线后的bug修复变得更容易，因此在发布之前修正每个bug的重要性已经没那么高了。但是，敏捷开发留给传统的QA和测试过程的时间也变少了，从而增加了bug进入产品的风险。

那么，怎样才能在快节奏的开发和bug之间取得平衡？你需要有个关于应用程序稳定性的反馈回路，以便使用稳定性监视工具进行跟踪。

客户的选择

客户能够选择他们使用的应用，因此要想留住客户，那么发布高质量、可靠的应用是非常重要的。举个我们都见过的常见例子。你要去开个会，于是你打开了一个打车因公。但很讨厌的是，Uber不好用而且崩溃了。但会还是要去开的，所以你使用Lyft及时地赶到了会场。由于这种情况太容易发生了，因此你可能会强迫自己改正每个导致这种情况的bug。但Jeff Atwoods提出了个很重要的问题（https://blog.codinghorror.com/not-all-bugs-are-worth-fixing/）：

“怎样才能区分出用户可能会遇到的bug，和用户可能根本不会遇到的bug？”

这个问题很重要，而且可以想像，竞争对手也在试图回答这个问题，所以他们会通过快速发布新功能来改进产品。

客户端的西部世界

并非所有bug都是平等的，在客户端应用中尤为如此。

JavaScript现在非常火，69%的开发者都使用JavaScript（https://insights.stackoverflow.com/survey/2018/#technology-programming-scripting-and-markup-languages），使之成为了最流行的编程语言。JavaScript的难题之一就是，在部署到浏览器之后，应用程序的行为可能会有区别。由于数量庞大的浏览器种类、版本、扩展和其他影响应用程序稳定性的因素，使得考虑所有可能情况几乎是不可能的。而且由于有这么多变种，许多稳定性问题其实都是极端情况，不会影响到绝大多数用户。例如，由于Internet Explorer 6现在使用的人非常少，而且它的行为十分怪异，因此调查IE6造成的bug基本上没什么用。

移动应用也给开发者带来了类似的挑战。安卓设备之间的碎片化现象非常严重。你知道吗？2015年市场上有24000种不同的安卓设备（https://opensignal.com/reports/2015/08/android-fragmentation/）！

移动设备上的部署的结果更难以预料，因为设备和设置会呈现巨大的区别，从而与应用交互时可能会造成各种问题。与JavaScript相似，许多bug都是极端情况，只会 影响到极其罕见的一部分手机。

花上几个小时去修改只影响到少数几个用户的bug是十分不划算的。

功能还是bug？二选一

正如Eric Sink所写的那样（https://ericsink.com/articles/Four_Questions.html），“关于软件质量的决定很困难且很重要，做出这些决定需要非常高的只会。有时‘bug’不应该被修改。”那么，怎样考虑bug的问题更合适？

将稳定性变成团队的KPI。

选一个能够达到的目标，将其作为团队有意义的努力方向。稳定性目标可以通过数据驱动的方式帮你在工程资源方面作出决策。在做sprint计划时，是应该分配时间修改问题，还是应该全力朝着产品地图努力？应用程序的稳定性可以帮你作出决定。

花些时间重新射审视监视数据是值得的，这样可以确保你能得到重要的反馈，或者了解是否需要改进策略。我留下几个问题供读者思考：

• 团队是否在考虑应用程序稳定性？
• 你在修复bug和构建新功能之间如何抉择？
• 你的团队怎样跟踪bug并设定bug修复的优先级？

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

作者：Kristine Pinedo，bugsnag的社区内容管理。

译者：弯月，责编：郭芮

“征稿啦！”

CSDN 公众号秉持着「与千万技术人共成长」理念，不仅以「极客头条」、「畅言」栏目在第一时间以技术人的独特视角描述技术人关心的行业焦点事件，更有「技术头条」专栏，深度解读行业内的热门技术与场景应用，让所有的开发者紧跟技术潮流，保持警醒的技术嗅觉，对行业趋势、技术有更为全面的认知。

如果你有优质的文章，或是行业热点事件、技术趋势的真知灼见，或是深度的应用实践、场景方案等的新见解，欢迎联系 CSDN 投稿，联系方式：微信（guorui_1118，请备注投稿+姓名+公司职位），邮箱（[email protected]）。