idea错误信息无法复制_如何修复无法复制的错误

idea错误信息无法复制

20,000英尺的噩梦是有史以来最具标志性的暮光区事件之一。 它讲述了神经病推销员鲍勃·威尔逊（Bob Wilson）的故事。 鲍勃从飞机窗外凝视着。 他惊讶地看到机翼上有一颗葛雷姆林飞来飞去。

鲍勃（Bob）越来越疯狂地尝试向其他乘客展示葛拉姆林。 这是没有用的。 当其他人透过窗户看时，小鬼怪消失了。 更糟的是，它显然开始拆卸飞机引擎，使所有人都处于致命的危险中。

有时，担任软件工程师的感觉就像是驾驶带有数百个机翼的飞机。 每个用户都不断地告诉您有关他们可以通过窗口看到的不同的gremlin的信息。 但是，当您寻找自己时，您不会发现任何异常。

我们需要修复错误，即使它们仅在某些情况下会发生在某些人身上。 即使我们不知道这些情况如何。 我们对我们创建的系统负全部责任。

修复这些无法复制的错误很困难，但通常是可以实现的。 这是您的怪物指南生存指南。

1.始终组织调查

作为工程师，明智地花费时间在工作上至关重要。 许多工程团队使用深入的方法来管理他们所做的新功能开发工作。 团队负责人通常会立即知道给定项目花费的时间超过预期的时间。 而且我们不希望工程师在单个sprint中完成整个积压工作。

但是，这些相同的团队常常无法应用这些相同的原理来解决错误。 许多工程师没有明确的期望就开始工作。 他们想知道，“我应该修复我最重要的错误，还是研究我最重要的用户故事？” 结果是工程师经常无法满足及时修复错误的期望。 很多时候，这些期望开始都是不现实的。

工程师最终对自己收件箱中放置了一个月甚至六个月的错误感到内。

写下你的假设

当无法复制错误时，您将无法期望知道需要花费多长时间才能修复该错误。 但是，你可以估算一个给定的调查将持续多久。

例如，您可能假设浏览器兼容性是错误的原因。 在Firefox中打开您的应用程序以检查此过程只需几分钟。

明确写下您的假设可提供您流程的可见性。 其他人可以很容易地看到您实际上正在处理错误。 在Asana，我们使用子任务来跟踪有关错误的假设，同时进行调查。

有时，假设不仅需要本地调试来解决。 另一个强大的技术是使用日志记录和断言来使您的假设更加清晰。

例如，您的错误可能是由一个值意外为null引起的。 在这种情况下，您可以在操纵值的地方周围添加日志，以获取更多的清晰度。

以这种方式使用日志记录可能是有效的，但它也是一个非常慢的迭代周期。 为了解决这个问题，请始终尝试同时为多个假设添加日志记录。

2.利用你的队友

我们认为工程是一种孤立的行为。 流行文化将工程师描述为孤独者，这部分定义了这一点。 我认为这也受到人们对工程的早期经验的影响。 大多数人通过从事单独项目来学习编码。 工程师的许多早期学习和成功经验都是关于独自工作的经验。

但是与几个团队成员一起进行大型项目是一个完全不同的世界。 这是您无法独自导航的一种。 要了解系统的行为异常，您最终需要了解系统工作人员的行为。

我们每个人都想成为独自解决错误的英雄。 但是，当我们选择花大量时间来研究无法解决的复杂错误时，这种趋势适得其反。

逐步提高知名度

当您花时间处理无法重现的错误时，请考虑如何在工作时逐步提升错误的可见性。

例如，您首先看了1个小时，然后将技术负责人包括在任务中。 然后，在错误处理了4个小时之后，请尝试招募3名可能知道正在发生什么的工程师。

您在这里寻找的不是让某人负责此错误。 如果已将错误分配给您，至关重要的是要保持明确的责任。 相反，您正在寻找让人们记住与您的搜索相关的重要信息的人。

最明显的形式是“哦，我上周打破了。” 另一种形式是“这让我想起了我去年解决的另一个问题……您是否尝试过检查广告阻止程序是否引起了此问题？”

升级漏洞的最大挑战是您自己对无法自行修复该漏洞的不安全感。 如果您真的不确定，建议您咨询经理。 他们可能会告诉您，找到可以帮助您的人是您的工作 。

成为历史学家

充分利用队友已经创建的书面上下文。

您的团队进行的每个代码更改都可能已经有一条提交消息，描述了其功能。 如果错误是最近开始的，请考虑扫描您团队在过去几天中所做的所有代码更改。 他们可能会指出您不了解的代码库中活跃的开发领域。

还有其他上下文来源。 检查这些内容，以了解代码库中正在发生的事情。

• 拉取请求注释
• 闲聊
• 任务注释

当然，这里的危险是这些信息源是完全无底的。 不要期望自己对正在发生的一切熟悉。 如果通读15分钟的最新更改没有任何效果，那么再花一个小时的时间不太可能会有所帮助。

3.进行现实检查

错误进入错误跟踪器。 错误跟踪器统计错误。 我们希望有零个错误，对吗？

我将不得不请你放弃那个梦想。 基本上没有没有错误的系统。 并非所有的错误都重要到可以修复。

是的，这包括标记为“重要”的错误。

不要专注于修复最后的错误。 与为您带来bug的人们建立清晰的沟通关系。 这样，您就可以找到解决技术问题的创造性解决方案，并了解用户的真正需求。

细细了解内部错误报告

“在这家公司，我们吃自己的狗食！” 在可以使用所创建软件的地方工作真是太棒了。 Dogfooding对于质量保证，动机和用户同理心具有不可思议的好处。 它还是无意义的内部错误报告的无穷来源。

用一点盐来做内部报告。 内部报告通常是我们发现错误的第一种方式，当它们准确无误时，它们可以在用户完全体验到错误之前就捕获它们。

我们自然会努力帮助我们认识的人并直接与他们互动。 因此，即使是一个人的内部报告，也常常感觉像是最紧急，最重要的错误类型。

但是请记住内部用户有多怪异。 他们对应用程序的使用可能不是典型的。 他们使用的软件版本可能与生产版本不同。 而且它们可能具有一整套特征标记，导致它们触及的代码路径与用户所遇到的情况大不相同。

因此，当内部错误报告针对某个用户而发生，并且无法复制时，有时明智的做法是仅等待看看是否有真正的用户点击了它。 而且，当然，随时准备减少生产。

并且请记住，外部用户也很奇怪。 我认为等待深入研究之前，至少要等一下至少三个真实用户是否遇到了错误，这是可以接受的。 （当然，这很大程度上取决于错误的严重程度）。

许多用户拥有奇怪的软件配置，侵入性浏览器扩展以及异常的网络状况。 这些通常会产生无法重现的问题。 通常，这些问题值得解决。 当然，我假设您还有其他重要事情要做。

让人们保持联系是您的工作

处理此类错误可能会给所有参与方带来烦恼和负担。 这包括客户支持代理和您的经理。 在不告知任何人的情况下，不要犯下努力解决棘手问题的错误。

我们只喜欢传递好消息，例如：

• “更新：我已经修复了该错误，现在已经发布！”

但是请记住，这也是个好消息：

• “我还没有解决这个问题，但是我同意这很重要，并且花了一些时间来解决它。”

对于在业务方面的员工而言，这种沟通模式是必不可少的工具。 他们需要经常与客户进行清晰的沟通。 不要通过保持沉默来阻止他们。 如果您花费任何时间从事某项任务，请不要离开它而不先写一些有关该任务的信息。

以这种方式建立通信信任也很重要，这样您就可以公开关闭或延迟错误报告。 如果计划在某一天完成某项工作，并且该截止日期没有到来，请不要让它默默地过去。 如果您主动对bug进行评论，以解释您为何更改截止日期，那么您将显得更加值得信赖。 如果您的延误决定有误，这也为您提供了获得反馈的机会。

建立您的错误管理心态

处理不可复制的错误很糟糕。 但这不是必须的。 通过好奇心，协作和横向思考来解决这些问题。 您可能会发现自己确实喜欢挑战。 关于我们使用的系统，有太多的知识要学习，一路挑战和惊喜。 专注于此，您将有望成为团队中最佳的漏洞修复工具。

如果您想帮助世界各地的团队解决诸如此类的难题，那么您应该在Asana与我合作 ！

特别感谢Justin Churchill，Bella Kazwell，Steven Rybicki和Mark Yao在这篇文章中的帮助。

翻译自: https://hackernoon.com/how-to-fix-bugs-that-you-cant-reproduce-1478c2eafb20

idea错误信息无法复制