【译文】bug 经济学

如果没有这么多的bug，软件开发会容易得多。在一个典型的软件应用程序中，目之所及都是源源不断的错误。有些错误会让用户痛苦不堪，有些虽然令人讨厌，但可以通过变通方法解决，剩下的大多是小麻烦。如果这听起来令人沮丧，很抱歉，这不是我的本意，我只是想以一个软件开发者和用户的双重身份来审视当前的软件质量状况。

在编写代码时，除非有可能危及生命或损失大量金钱，否则软件开发人员通常都有动力快速编写代码，因为上市时间几乎总是被当权者认为是至关重要的。因此，开发人员编写的代码在 0.1% 的时间内（在我的机器上正常运行）到 99.9% 的时间内（大部分时间没有错误）都能正常运行。鉴于软件开发人员实际编写的应用程序代码只是计算机上运行的全部代码的一小部分（还有许多依赖项，如操作系统、数据库、第三方库、网络服务等），因此期望应用程序 100% 无错误几乎是不可能的。但是，我们往往远远达不到假设的 100%。

对我来说，最令人沮丧的莫过于你所依赖的功能中出现了一个关键的错误，而这个错误一直都在工作，但开发人员却在最新的更新中把它弄坏了。他们怎么能把事情搞得一团糟，还发布这么明显的故障？难道开发人员用的不是自己的软件吗？答案是……不，不是，至少不是你现在使用的方式。他们不是驾驶飞机的飞行员，而是制造飞机的工程师。事实上，作为用户，你可能比开发人员更了解你最喜欢的功能的复杂性。

既然bug是生活的一部分，如果他们能迅速修复，你可能会准备原谅一个关键的错误，但如果他们没有呢？一个错误可能只影响一小部分用户，因此开发人员可能很难重现这个错误。然而，开发人员的工作不就是预测所有可能出错的事情吗？答案又是否定的。在一个理想的世界里，金钱不是问题，你可以花尽可能多的时间来编写高质量的代码，这样就有可能开发出几乎完美的软件。但是，我们生活的世界并不理想。如果没有多少用户愿意为高可靠性的软件支付高昂的费用，那么经济上的激励显然是不存在的。

即使眼前的经济状况对我们不利，我们还能写出基本没有错误的软件吗？毕竟，从长远来看，生产高质量的软件可能会成为一项重要的竞争优势，因为开发人员可以将更多的时间用于改进软件，而不是修复错误，这就引出了科学方法在软件开发中的应用，或者说往往是缺乏科学方法的应用。

科学方法就是形成一个可证伪的假设，并试图通过找到至少一个相互矛盾的条件来反驳它。然而，在软件开发中，人们通常会采取更为乐观的方法。是的，我们会对代码进行测试，看它是否能在特定条件下工作，但这些条件通常会带来幸福路径。测试边缘情况，即大多数错误的根源，通常是一个较低的优先级。

那么，我们做错了吗？难道我们不应该更加重视查找和测试边缘情况吗？答案还是在于经济学。正确处理大量的边缘情况意味着要做大量的工作，而这些工作并不总是能得到昨天就需要某个功能的用户的赞赏。那么，时间紧迫的软件开发人员会怎么做呢？他们用 try-catch 代码块封装快乐路径代码，如果出错，就返回 “未知错误 “信息。你现在知道这些神秘的错误信息从何而来了吧。

批评漏洞百出的软件很容易，但如果市场上的大多数用户更喜欢漏洞更多但功能加倍的软件，那么只生产少数功能的高可靠性软件可能就没有什么经济意义了。

如果我是在为软件开发中的平庸辩护，只是因为没有经济激励，那我不是这个意思。顾名思义，任何以工作为荣的软件开发人员都不想开发出不那么优秀的软件，但好的工程设计是一个平衡游戏。我们通常会给你一个时间预算，并希望你在预算范围内做到最好。优秀的工程师知道如何协商，而不是盲目地照办。他们可能会提出削减或简化功能，以避免过于分散，而优秀的管理层也会倾听他们的意见。

本文文字及图片出自 Economics of Bugs

分享这篇文章：

你的反应是：

• 0
• 俺的神呀 0
• 赞一个 0
• 飘过~ 0
• 强 0
• 很实用 0
• 好文 0
• 笑死了 0
• mark 0
• 敬佩 0
• 垃圾 0
• 0

看样子你已经点过这个了！

抱歉，你最多只能点三个！