我是一个前端开发者,但我想这个故事对任何开发者都会引起共鸣的
有人向你反馈了一个 bug。 “26 楼会议室的灯亮着。它需要被熄灭。”bug 的备注里写道“你应该能在 5 分钟内搞定,只要按一下开关就好了。“ 你去了 26 楼的会议室。灯的确亮着,但房间里没有灯的开关。
所以,你准备安装一个。但设计师说,它会破坏房间的美感。另外,墙壁是混凝土。你需要合适的工具才能安装开关。但是,没有人会批准购买这些工具。如果没有合适的工具,安装开关将需要两天。他们希望你现在就能把灯关上,因为他们害怕 CEO 可能心血来潮决定去 26 楼逛逛,并恰好路过了会议室,问为什么灯是亮着的。
现在你不断地收到邮件,询问为什么会议室的灯还是亮着的。现在你不得不群发一封邮件说明情况,几人开始了一个恐慌的电子邮件链。
你知道,如果你期待着问题能够被邮件讨论解决(而不实际做点什么),这个问题永远也不会得到修复。bug 系统里,这个 bug 归你处理,而且它的最后期限就是今天。如果问题没有解决,会有麻烦的是你。所以,你设法进到了 26 楼走廊的天花板里,找到了会议室灯的电线,一刀切断。问题解决了。
为了平息在电子邮件链里的恐慌,你(再次群发邮件)说明了你是如何解决问题的。
邮箱安静了一阵。当它再次响个不停的时候,每个人都在担心,现在会议室的灯无法开启和关闭。如果 CEO 想在那里开会怎么办?因此,他们要求你“把灯的电线牵引到地下室去”。当有人需要开关灯时,他们会通知你到地下室去,连接或断开电线。
你抗议这个荒谬的解决方案。你的上司说,“是的,我知道这不理想。但它是现在唯一的解决方案。“
这时,你面临着选择。你可以照着他们说的做,或者辞职以示抗议,另谋高就。但你知道,一旦你开始了新的工作,新的他们很可能也会要求你做这么白痴的事,如果不是更白痴的话。
你把 26 楼的电线牵引到了地下室。当你进入地下室后,发现已经有几十条电线挂在墙上,你知道你不是一个人,也知道了这个白痴想法是从哪来的。你调整好了电线,尽人事地贴上标记,默默地向下一个可能处理它的哥们道歉。
终于,你回到了你的办公桌,你收到了一个新的 report。 QA 重新开启了 bug。bug 描述里说“房间还是亮着。”
你回到 26 楼的会议室。灯是灭着的。你返回办公桌前,关闭了 bug,注明你已经亲自检查过了。
QA 再次重新开启了 bug。“房间还亮着”bug 描述里坚持。再次亲眼确认灯泡灭着后,你将情况汇报给了上司。他建议你去地下室检查电线。你抗议说你正直盯盯地看着灯,它就是灭着的。 “我知道,但去检查一下。这样一来你就可以告诉 QA 你确认了所有流程。”
你叹了口气,前往地下室。果然,电线没有连接,切口两端都好好地被包裹着。它们不可能以任何你能理解的方式导电。
你向 QA 反馈,你检查了电线,它们没有连接着,你正看着灯泡,它是熄灭的。
“我不是指灯泡,”QA 说。 “bug 里描述的是房间里的光。房间现在仍然不够暗。你应该拉下百叶窗。“
你回应说百叶窗不归你管,bug 描述的是灯光。
QA 不相信你,发出一组电子邮件,询问 bug 是否包含百叶窗拉下的问题。
你很是等待了一会,邮箱又一次响起了。
“从理论上说,”他们问,“如果光太亮或太暗的话,在 26 楼会议室开会的人能自由拉上或拉下百叶窗吗?”
是的,他们可以,你回复。 “任何一个普通人都能做到吗?他们就不需要你做了吗?“是的,任何普通人。不,他们不会需要你。任何人都可以做到这一点。 “太好了。那么,灯光问题暂时到此为止。我会安排如何处理百叶窗的会议。“
bug 被关闭了。现在,CEO,可能从所有关于 26 楼会议室的讨论中感觉到了什么,希望在那里开会。你收到了几封希望开灯的惊慌失措的邮件。
你去了地下室,连上电线,并返回办公桌。你的收件箱多了 32 个新的消息。 “出问题了-灯还是熄灭的!”“有个问题-没有灯光!” “你收到我们发的邮件了吗?等等等等。
第 32 封邮件说道:“没事-灯亮了。”
这个(指 32 封邮件)过程,或多或少地,在开关灯时反复发生。
如果要说有什么好消息的话,那就是在会议结束后,大家甚至都忘记了 26 楼有个会议室,你也不需要对它做任何处理。
文本转自:程序师
英文原文:When someone gives you a bug (long)
相关推荐
灯的确亮着,但房 //我是一个前端开发者,但我想这个故事对任何开发者都会引起共鸣的 有人向你反馈了一个bug。“26楼会议室的灯亮着。它需要被熄灭。”bug的备注里写道“你应该能在5分钟内搞定,只要按一下开关...
3. **状态跟踪**:每个Bug都有一个状态流程,如新建、待确认、处理中、已解决等,这有助于跟踪问题的处理进度。 4. **任务分配**:项目经理或负责人可以将Bug分配给特定的开发人员处理。 5. **评论与讨论**:团队...
【标题】"PHP实例开发源码—bug反馈系统"是一个基于PHP编程语言的项目,旨在构建一个用于收集、管理和处理软件或网站中发现错误(bug)的反馈系统。这个系统对于任何开发团队来说都至关重要,因为它能有效地追踪问题...
- **举报机制**: 如果发现有人故意利用BUG,可以通过游戏内的举报系统向官方反馈。 综上所述,尽管“圣诞地图BUG”看似能够给玩家带来短期的利益,但从长远来看,维护良好的游戏生态更加重要。作为玩家,我们应当...
在软件开发过程中,Bug管理是至关重要的一个环节。"Bug状态流程图"是对软件缺陷处理过程的一种可视化表示,它清晰地展示了从发现Bug到解决Bug的各个阶段,以及每个阶段可能的状态转换。以下是对这个流程图的详细解读...
- **New**:当测试人员首次发现并提交一个新的Bug时,其状态会标记为New。这是Bug生命周期的起始状态,表明该Bug尚未经过任何处理。 - **Open**:一旦开发团队确认了New状态下的Bug,并将其分配给具体的开发者进行...
如果一个用户的默认角色不包含所需产品的访问权限,则会导致无法访问相应产品。 #### 2.2 产品未正确关联至用户 即使用户拥有适当的角色,但如果具体的产品没有正确地与该用户关联起来,仍然会出现访问限制。 ####...
**Bug解决描述(由开发人员填写)**:开发人员修复问题后,应向测试负责人反馈。对于简单问题,可直接回复“已解决”或“fixed”。复杂问题则需提供详细的解决方案,便于测试人员理解和验证。 **Bug关闭描述(由...
在这款游戏中,玩家将与一个不断学习和适应的AI系统进行互动,这使得每一次的游戏过程都有可能带来全新的挑战和策略。下面,我们将详细探讨这款游戏的各个组成部分以及相关的知识点。 首先,游戏攻略文档提供了玩家...
8. **社区求助**:如果使用的是开源库或第三方组件,可以在其官方论坛或社区发帖寻求帮助,看看是否有人遇到类似问题并已找到解决方案。 修复BUG后,还需要进行充分的测试,确保问题已彻底解决,并未引入新的问题。...
在IT项目管理中,软件Bug详细记录表是一个至关重要的文档,它用于跟踪和管理软件开发过程中的错误和问题。这份2021-2022年的专题资料着重介绍了如何有效地记录和处理软件Bug,以确保项目的质量和进度。以下是关于...
BugFree是一款广泛应用于软件开发中的缺陷管理工具,它帮助团队有效地跟踪和管理软件中的错误,以提高产品质量。本文主要分享了使用BugFree时的一些注意事项,旨在优化团队协作和提升问题解决效率。 首先,确保在...
BUG管理是问题管理的一个子集,专注于软件中的错误或异常行为。Java开发者使用BUG管理系统(如Bugzilla或GitHub Issues)来记录发现的BUG,跟踪修复进度,并进行回归测试以验证BUG是否已解决。良好的BUG管理能确保...
传统的手动记录和跟踪方式往往效率低下,易出错,因此需要一个专门的Bug管理工具来自动化这一过程,提供统一的平台,使团队成员可以清晰地了解每个Bug的状态,提高协作效率。 1.2 功能概要 该工具的核心功能包括...
未来规划上,八阿哥致力于打造一个轻量级的Jira+Teambition结合的SaaS工作台,不仅提供bug管理服务,还将拓展其他相关服务,以满足产品研发团队的全方位需求。团队计划通过融资进一步优化产品,使其无可替代,并加大...
1. **Bug ID**:每个Bug都有一个唯一的标识符,方便追踪和管理。这有助于确保每个问题都能被正确地分配和解决。 2. **发现人**:记录发现Bug的人员,可能是测试人员、开发人员或用户,他们的反馈对定位问题至关重要...
1. **BUG ID**:每个错误都有一个唯一标识符,方便跟踪和管理。这通常是自动分配的,便于排序和查询。 2. **标题**:简洁明了地概述BUG的核心问题,以便于快速理解。 3. **描述**:详细地描述错误的现象,包括出现...
在软件开发过程中,Bug报告是一个至关重要的文档,它记录了软件中出现的问题,便于开发团队及时修复。以下是一个经典的Bug报告模板的详细解释: 1. **BUGID**: 这是Bug的唯一标识符,由Bug管理系统自动生成,用于...