20,000英尺的梦m 是有史以来 最具标志性的暮光区剧集之一。 它讲述了一个神经质的推销员鲍勃·威尔逊&＃xff08;Bob Wilson&＃xff09;的故事。 鲍勃从飞机窗外凝视着。 他看到机翼上飞来飞去的葛雷姆林&＃xff0c;感到有些惊讶。
鲍勃&＃xff08;Bob&＃xff09;越来越疯狂地尝试向其他乘客展示葛拉姆林。 这是没有用的。 当其他人透过窗户看时&＃xff0c;小鬼怪消失了。 更糟的是&＃xff0c;它显然开始拆卸飞机引擎&＃xff0c;使所有人都处于致命的危险中。
有时&＃xff0c;担任软件工程师的感觉就像是驾驶带有数百个机翼的飞机。 每个用户都不断地告诉您有关他们可以通过窗口看到的不同的gremlin的信息。 但是&＃xff0c;当您寻找自己时&＃xff0c;您不会发现任何异常。
我们需要修复错误&＃xff0c;即使它们仅在某些情况下会发生在某些人身上。 即使我们不知道这些情况如何。 我们对创建的系统负全部责任。
修复这些无法复制的错误很困难&＃xff0c;但通常是可以实现的。 这是您的怪物指南生存指南。
1.始终组织调查 作为工程师&＃xff0c;至关重要的是您明智地花时间在工作上。 许多工程团队使用深入的方法来管理他们所做的新功能开发工作。 团队负责人通常会立即知道给定项目花费的时间超过预期的时间。 而且我们不希望工程师在单个sprint中处理整个待办事项。
但是&＃xff0c;这些相同的团队经常无法应用这些相同的原理来解决错误。 许多工程师没有明确的期望就开始工作。 他们想知道&＃xff0c;“我应该修复我最重要的错误&＃xff0c;还是研究我最重要的用户故事&＃xff1f;” 结果是工程师经常无法满足及时解决错误的期望。 很多时候&＃xff0c;这些期望开始都是不现实的。
工程师最终对自己收件箱中放置了一个月甚至六个月的错误感到内。
写下你的假设 当无法复制错误时&＃xff0c;您将无法期望知道需要花费多长时间才能修复该错误。 但是&＃xff0c;你可以 估算一个给定的调查将持续多久。
例如&＃xff0c;您可能假设您的错误的浏览器兼容性有问题。 在Firefox中打开您的应用程序以检查此过程只需几分钟。
明确写下您的假设可提供您流程的可见性。 其他人可以很容易地看到您实际上正在处理错误。 在Asana&＃xff0c;我们在调查时使用子任务跟踪有关错误的假设。
有时&＃xff0c;假设不仅需要本地调试来解决。 另一个强大的技术是使用日志记录和断言来使您的假设更加清晰。
例如&＃xff0c;您的错误可能是由值意外为空引起的。 在这种情况下&＃xff0c;您可以在操纵值的地方周围添加日志&＃xff0c;以获取更多的清晰度。
以这种方式使用日志记录可能是有效的&＃xff0c;但它也是一个非常慢的迭代周期。 为了解决这个问题&＃xff0c;请始终尝试同时为多个假设添加日志记录。
2.利用您的队友 我们认为工程是一种孤立的行为。 流行文化将工程师描述为孤独者&＃xff0c;这部分定义了这一点。 我认为这也受到人们对工程的早期经验的影响。 大多数人通过从事单独项目来学习编码。 工程师的许多早期学习和成功经验都是关于独自工作的经验。
但是与几个团队成员一起进行大型项目是一个完全不同的世界。 这是您无法独自导航的一种。 要了解系统的行为方式&＃xff0c;您最终需要了解系统工作人员的行为。
我们每个人都想成为独自解决错误的英雄。 但是&＃xff0c;当我们选择花大量时间研究无法解决的复杂错误时&＃xff0c;这种趋势适得其反。
逐步提高知名度 当您花时间处理无法重现的错误时&＃xff0c;请考虑如何在工作时逐步提高错误的可见性。
例如&＃xff0c;您首先看了1个小时&＃xff0c;然后将您的技术主管包括在任务中。 然后&＃xff0c;在错误处理了4个小时之后&＃xff0c;请尝试招募3名可能知道正在发生什么的工程师。
您在这里寻找的不是让某人负责此错误。 如果已将错误分配给您&＃xff0c;至关重要的是要保持明确的责任。 相反&＃xff0c;您正在寻找让人们记住与您的搜索相关的重要信息的人。
最明显的形式是“哦&＃xff0c;我上周打破了。” 另一种形式是“这让我想起了我去年解决的另一个问题……您是否尝试过检查广告阻止程序是否引起了此问题&＃xff1f;”
不断升级的漏洞可见性所面临的最大挑战是您自己对无法自行修复该漏洞的不安全感。 如果您确实不确定&＃xff0c;建议您咨询经理。 他们可能会告诉您&＃xff0c;找到可以帮助您的人是您的工作 。
成为历史学家 充分利用队友已经创建的书面语境。
您的团队进行的每个代码更改可能已经有一个提交消息&＃xff0c;描述了它的作用。 如果错误最近才开始出现&＃xff0c;请考虑扫描您团队在过去几天中所做的所有代码更改。 他们可能会指出您不知道的代码库中活跃的开发领域。
上下文还有其他来源。 检查这些内容&＃xff0c;以了解代码库中正在发生的事情。
当然&＃xff0c;这里的危险是这些信息源是完全无底的。 不要期望自己对正在发生的一切熟悉。 如果通读最新更改的15分钟没有产生任何效果&＃xff0c;那么再花一个小时的时间不太可能会有所帮助。
3.进行现实检查 错误进入错误跟踪器。 错误跟踪器统计错误。 我们希望有零个错误&＃xff0c;对吗&＃xff1f;
我将不得不请你放弃那个梦想。 基本上没有没有错误的系统。 并非所有的错误都重要到可以修复。
是的&＃xff0c;这包括标记为“重要”的错误。
不要专注于修复最后的错误。 与为您带来bug的人们建立清晰的沟通关系。 这样&＃xff0c;您就可以找到解决技术问题的创造性解决方案&＃xff0c;并了解用户的真正需求。
细细了解内部错误报告 “在这家公司&＃xff0c;我们吃自己的狗食&＃xff01;” 在某个可以使用所创建软件的地方工作真是太棒了。 Dogfooding对于质量保证&＃xff0c;动机和用户同理心具有不可思议的好处。 它还是无意义的内部错误报告的无穷来源。
细细记录内部报告。 内部报告通常是我们发现错误的第一种方式&＃xff0c;当它们准确无误时&＃xff0c;它们可以在用户完全体验到错误之前就捕获它们。
我们自然会努力帮助我们认识的人并直接与他们互动。 因此&＃xff0c;即使是一个人的内部报告&＃xff0c;也常常感觉像是最紧急&＃xff0c;最重要的错误类型。
但是请记住内部用户有多怪异。 他们对应用程序的使用可能不是典型的。 他们使用的软件版本可能与生产版本不同。 而且它们可能具有一整套功能标志&＃xff0c;导致它们触及的代码路径与用户发生的情况完全不同。
因此&＃xff0c;当内部错误报告针对用户发生而无法复制时&＃xff0c;有时&＃xff0c;最好等待真正的用户点击它。 而且&＃xff0c;当然&＃xff0c;随时准备减少生产。
并且请记住&＃xff0c;外部用户也很奇怪。 我认为等待深入研究之前&＃xff0c;至少要等一下至少三个真实用户是否遇到了错误&＃xff0c;这是可以接受的。 &＃xff08;当然&＃xff0c;这很大程度上取决于错误的严重程度&＃xff09;。
许多用户拥有奇怪的软件配置&＃xff0c;侵入性浏览器扩展以及异常的网络状况。 这些通常会产生无法重现的问题。 通常&＃xff0c;这些问题值得解决。 当然&＃xff0c;我假设您还有其他重要事情要做。
让人们保持联系是您的工作 对此类错误进行处理可能会给所有相关人员带来烦恼和负担。 这包括客户支持代理和您的经理。 在不告知任何人的情况下&＃xff0c;不要犯下努力解决棘手问题的错误。
我们只喜欢传递好消息&＃xff0c;例如&＃xff1a;
“更新&＃xff1a;我已经修复了该错误&＃xff0c;现在已经发布&＃xff01;” 但是请记住&＃xff0c;这也是个好消息&＃xff1a;
“我还没有解决这个问题&＃xff0c;但是我同意这很重要&＃xff0c;并且花了一些时间来解决它。” 对于在业务方面的员工来说&＃xff0c;这种沟通模式是必不可少的工具。 他们需要与客户频繁且清晰地沟通。 不要通过保持沉默来阻止他们。 如果您花任何时间从事某项任务&＃xff0c;请不要离开它而不先写一些 有关该任务的信息。
以这种方式建立沟通信任也很重要&＃xff0c;这样您就可以公开关闭或延迟错误报告。 如果计划在某一天完成某项工作&＃xff0c;并且该截止日期没有到来&＃xff0c;请不要让它默默地过去。 如果您主动对该错误做出评论&＃xff0c;说明您为何更改截止日期&＃xff0c;那么您将显得更加值得信赖。 如果您的延误决定有误&＃xff0c;这也为您提供了获得反馈的机会。
建立您的错误管理心态 处理不可复制的错误很烂。 但这不是必须的。 通过好奇心&＃xff0c;协作和横向思考来解决这些问题。 您可能会发现自己确实喜欢挑战。 关于我们所使用的系统&＃xff0c;有太多的知识要学习&＃xff0c;一路挑战和惊喜。 专注于这一点&＃xff0c;您将有望成为团队中最佳的漏洞修补程序。
如果您想帮助世界各地的团队解决诸如此类的难题&＃xff0c;那么您应该在Asana与我合作 &＃xff01; 特别感谢Justin Churchill&＃xff0c;Bella Kazwell&＃xff0c;Steven Rybicki和Mark Yao在本文中的帮助。
From: https://hackernoon.com/how-to-fix-bugs-that-you-cant-reproduce-1478c2eafb20
京公网安备 11010802041100号