软件错误在技术领域很常见。如果您曾经编写过十行以上的代码，那么您很可能不小心导致了其中一行代码的出现。 现在，我希望您回想一下您上次收到客户或同事发来的因错误而惊慌失措的消息是什么时候。结果如何？该错误是否如此紧急以至于您必须停止正在做的事情？ 在本文中，我们将尝试挑战有关错误的传统思维，并探讨每个错误给您和您的团队带来了多少损失。 关于我 大家好👋，我叫 Krste，是一名全栈开发人员，在初创公司工作了七年多。最近，我与他人共同创立了  ，这是一个错误监控平台，可以向软件团队发出有关面向用户的关键错误的警报。 Bugpilot 我写这篇文章的目的是挑战关于错误的传统思维以及“我们需要尽快修复它！”心态，质疑探索每个问题的真实成本的必要性。  100% 无错误的软件。神话还是现实？ 实现 100% 无错误软件的目标一直是一个棘手的目标。创建无错误应用程序的想法似乎很理想， 但实际上可能吗？ 事实上，由于复杂的业务逻辑、人为错误以及技术的不断更新，软件错误是不可避免的。即使进行仔细的测试和质量检查，也很难完全消除它们。 然而，得益于新的开发人员工具和改进的流程，团队现在正在以闪电般的速度发布新功能，以保持相关性和竞争力。 而且，随着代码库的任何变化，某些东西总是有可能被破坏。 （必须支持多种设备和多种浏览器根本没有帮助。） 当然，在某些情况下，错误必须接近于零。某些行业，如银行、医疗和航空航天，必须确保将错误保持在最低限度，因为它们 。 可能会导致人员伤亡 这就解释了为什么这些行业中的大多数软件都是用几十年前的技术编写的，以及为什么人们现在不愿接触它。 但最后，我们必须问自己，   ”对于我们大多数构建营销工具和 CRM 的人来说，我相信 我将尝试解释原因。 “这一切都值得吗？ 修复错误通常比留下它们更昂贵。 并非所有错误都是一样的 想象一下，您正在开发一个电子商务网站，一个错误破坏了结账流程，导致客户无法完成购买。 很明显，这个错误需要立即引起注意，因为它直接影响核心功能，并可能导致销售损失和客户不满意。 同样 。 ，我们不能像处理与更新个人资料照片相关的问题一样处理注册页面中阻止新用户加入我们新的乘车共享应用程序的错误 这些黑白示例表明，我们不仅需要检测，而且 然而，事实上，事情并不是非黑即白的。大多数情况都属于灰色地带。 需要一种方法来了解错误的影响。 那么问题就变成了：我们如何知道要修复什么？  “我们现在必须修复它，否则客户就会离开” 我注意到，我们倾向于为客户发现的错误添加“额外”的紧迫感。 当您的一个 客户遇到一个小问题时，您可能遇到过类似的情况，而您的整个团队都被消息淹没，就像世界着火了 🔥 大   ”Giovanni 抱怨他们无法右对齐文本  1 他们是重要客户。我们现在必须修复这个错误！” 11  - 你的老板 根据我的经验，面向客户的角色（例如客户成功、支持和销售）往往会根据客户的反应及其对声誉的影响来确定问题的优先级。这就是为什么对他们来说一切都显得很重要，这是可以理解的。 没有人愿意给人留下不好的印象或负面声誉，而这正是错误可能导致的。 受错误影响的用户越多，修复它（可能）就越重要 有时，生产问题在发生时就得到处理。尤其是我们的开发人员会立即发现收件箱中的任何错误或编码错误。 您或您的团队可能正在使用 或 等工具来监视并在发生错误时收到通知。 Sentry Bugsnag 当发现任何错误时，它会迅速分配给开发人员，而每个人都在不耐烦地等待 Slack 中的更新。 通常，这些工具会根据错误发生的频率以及受影响的用户数量来确定错误的优先级。  Human.prioritizeBugs() 然而，大多数团队中大多数错误的优先级可能是由产品负责人或首席开发人员决定的。 这些角色通常了解业务逻辑、底层技术、当前工作负载和即将到来的优先事项并相应地进行计划。 他们的 可能如下所示： 优先级标准 第一个问题，但它已经变得有点棘手了。什么是 关键没有明确的定义。如果核心功能无法使用，那么很明显我们必须修复它。 这是否重要？ 关键？ 但是，正如您在上面的示例中看到的，如果重要客户受到影响怎么办？ 只有一个？每个人？我们知道吗？当大量用户受到影响时，您可能希望解决该问题，即使它与次要功能相关。 它影响了多少客户？ 接下来，  流程的负责人会询问修复问题需要多长时间。如果只需要几个小时，他们就会想方设法将其挤入本周的工作中。  修复它需要多少时间？ “Bug Triage”  “（尽快）修复还是不修复，这就是问题所在。” 开发人员在处理“紧急”错误时经常面临困境。他们可能要么急于完成当前的任务并修复错误，可能会在此过程中引入新的错误；要么他们经常忽略 ，因为他们可能会突然将注意力转移到错误上，完全放弃当前的任务。 上下文切换开销 这些场景存在三个重大问题： 团队的优先级不正确，可能导致浪费时间并修复不太相关的错误。 给非关键错误添加不必要的紧迫性会导致团队不必要地转移焦点。 在解决错误之前，重要的是要考虑其 。那么，一个错误实际上给团队带来了多少损失呢？修复它的费用合理吗？ 成本 修复错误的成本有多高？ 你听说过 “天下没有免费的午餐”这句话吗？ 当我们谈论成本时，作为开发人员，我们首先想到的是基础设施成本、服务器、Lambda 函数、MongoDB 集群的成本等等。 然而，当谈到错误时，我谈论的是与人类相关的成本： 。 注意力 上下文切换 如果您学过计算机工程或者曾经读过操作系统的工作原理，您可能听说过上下文切换。 在计算中， 是存储进程或线程状态的过程，以便稍后可以恢复并继续执行，然后恢复之前保存的不同状态。 上下文切换  （来自 [维基百科]（https://Context switch https://en.wikipedia.org › wiki › Context_switch）） 操作系统上下文切换的一种情况可能是多任务处理： 上下文切换是多任务处理的特征，它允许进程从 CPU 切换，以便另一个进程可以运行。 我以前在哪里听过这些话🤔？ - 是啊：  “我是多任务处理大师。” 当某人试图同时执行两项任务、从一项任务切换到另一项任务或快速连续执行两项或多项任务时，就会发生多任务处理。 一边和朋友聊天一边洗衣服可能会很好。当我们执行复杂的心理任务 （例如编写代码）时，棘手的部分就出现了。 以确定其成本。他们测量了人们完成任务所需的时间以及在任务之间切换的时间成本。结果如下： 心理学家对任务转换进行了多项实验，   “虽然切换成本可能相对较小，有时每次切换只需零点几秒，但当人们在任务之间反复来回切换时，这些成本加起来可能会很大。 …… 在任务之间切换可能会占用某人高达 40% 的生产时间。”  “能打扰你几分钟吗？” 想象一下：你被锁定，完全沉浸其中，没有什么可以阻止你完成这个新的、闪亮的功能。外部世界甚至不存在——只有你和你的代码。但随后，您突然听到铃声……手机上有新通知。 这是你的朋友这个周末约你出去喝酒。就这样， ，你生命中接下来的20分钟就过去了。 噗 或者，您可能刚刚收到同事发来的 Slack 消息，询问您是否有时间帮助解决特定问题。 第二种情况比第一种情况更容易被接受吗？ 好吧，最终， 以及对 414 名程序员的调查 (   ) 发现： 这并不重要。 根据对 86 名程序员使用 Eclipse 和 Visual Studio 记录的 10,000 次编程会话的分析 Parnin:10 程序员从中断中恢复工作后需要 10 到 15 分钟才能编写更多代码。 当编辑方法期间被中断时，只有 10% 的程序员会在一分钟之内恢复工作。 程序员一天可能只进行一次不间断的 2 小时会议。 当涉及无用的会议时，开发人员倾向于避免（ ）上下文切换。尽管如此，我相信当我们在“开发人员任务”之间进行上下文切换并完全忽略其负面影响时，我们可能会在某种程度上盲目。 并且讨厌 最后的想法 在现实世界中，我们总是处理有限的资源，无论是金钱、时间还是 。 注意力 修复错误是有代价的。  “不”是对一件事说不。  “是”对很多事情来说都意味着“不”。 —— 贾森·弗里德 表面上看，多任务处理似乎很高效，但任务之间的切换需要更多时间，最终会引入更多错误。 对修复错误说“是”意味着对某个功能说“不”。 可以帮助您更好地选择哪些错误值得放弃一切，哪些错误不值得（大多数不值得）。 了解上下文切换的隐藏成本 我们应该停止关心错误吗？ 嗯，不。 冷静地坐下来接受错误可能是一项挑战。我们都有一种内心渴望制作高质量的作品并构建一些我们可以引以为豪的东西。 然而，我们至少应该意识到修复错误的成本，并问自己：  “值得修复吗？” 不幸的是，那些讨厌的错误经常会妨碍我们。 正如 Tom De Marco 在他的 一书中所写，这也许可以解释为什么很难停止关心质量： 《Peopleware》 我们都倾向于将自尊与我们生产的产品的质量紧密联系在一起——不是产品的数量，而是质量。 （出于某种原因，生产出大量平庸的东西并不能带来满足感，尽管这可能正是特定情况所需要的。）  – 人件 我们应该在错误预防上投入更多精力吗？ 正如我之前提到的，在许多行业你别无选择。在那里，您必须采取一切必要的措施来防止错误发生并尽快纠正它们。 但是，对于大多数应用程序来说， 额外的努力值得吗？  PS 归根结底，即使我们有一根魔杖可以修复所有错误，我们的用户仍然会找到一种方法来滥用我们的应用程序😅 

Find hidden bugs

Book a Call

Bugpilot

該音頻是用故事的原始語言製作的！

错误会扼杀你的动力吗？

About Author

註釋

標籤

这篇文章刊登在

Related Stories

从论坛到信息流：社交媒体算法如何塑造数字互动

架构师指南：构建 AI/ML 数据湖参考架构

成功云迁移的完整指南：策略和最佳实践

使用这 18 种开发工具来提高你的工作效率 🚀🔥

从论坛到信息流：社交媒体算法如何塑造数字互动

架构师指南：构建 AI/ML 数据湖参考架构

成功云迁移的完整指南：策略和最佳实践

使用这 18 种开发工具来提高你的工作效率 🚀🔥

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps