有人向我反馈了一个bug

原文地址
When someone gives you a bug (long)

译文

(我是一个前端开发者，但我想这个故事对任何开发者都会引起共鸣的)

有人向你反馈了一个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楼有个会议室，你也不需要对它做任何处理。