和你们一样，我也是一个普普通通的前端开发者，在日常工作中，大部分时间不是在写新代码，而是在改代码，或是需求被改了，或是报bug了。

当别人想我们报一个bug，直到我们把bug完整的修复好，整个过程是一个怎样的经历？

下面用一个电灯维修工的故事类比一下，相信会引起很多开发者共鸣：

假如你是一个电灯维修工程师。一天晚上，有人想你反馈了一个bug：“18楼会议室的灯亮着，你要去把它熄灭”。bug的备注里还写到：这个bug很简单，你只需要按一下开关就可以关掉了，你应该在5分钟内修复这个不管。

你上到了18楼的会议室，灯的确是亮着，但是房间里没有这盏灯的开关。

怎么办？你准备安装一个开关。这个时候设计师会跟你说，它会破坏房间的美感。另外，墙壁是混凝土做的，你得有合适的工具和其他人的配合才能安装。但此时此刻，你找不到这些工具和人员来帮你。

如果没有这些辅助工具，安装开关，保守估计要2天时间。但是他们希望你只花5分钟就把灯关掉，因为他们害怕CEO哪天会经过18楼会议室，问为什么灯是亮着的，怕被问责。

5分钟过去了，你的手机响个不停，他们反复问你为什么灯还亮着，为什么按一下开关就能关掉这么简单的事你要弄这么久。

为了尽快解决问题，你实在没办法，所以，你设法进到了 18 楼走廊的天花板里，找到了会议室灯的电线，一刀切断，灯关掉了，问题解决了，你告诉了他们你的解决办法。

你的手机也安静了，但好景不长，他们又有了新的疑问：线被你切掉了，如果哪天我们想开启会议室的灯，怎么办？因此，他们要求你把这盏灯的线牵引到地下室去，因为那里有开关，等他们需要开灯的时候，就通知你去地下室帮他们开灯。

你抗议这个荒谬的解决方案。但是你的上司说：“是的，这个解决办法不理想，但是现在是唯一的解决方案”。

这个时候你心里骂了他们一句：SB！现在你要么按照他们的“荒谬”要求来做，要么辞职另谋高就，但你想了想，一旦到了新的工作环境，也难免会遇到这种荒谬的事情。

你咬咬牙，把18楼会议室的线牵引到了地下室，你发现已经有10几条线是从其他地方牵引过来的，这种荒谬的做法，你不是第一个做。你小心翼翼地把线牵引号，并尽人事地给左右地线做好了标记。

终于，你回到了你的办公桌，把bug标记成：“已修复”。可刚过不就，测试员又重新开启了bug，并备注说：“会议室还是亮着的”。

你回到 18 楼的会议室。灯是灭着的。你返回办公桌前，关闭了 bug，注明你已经亲自检查过了。 

测试员再次重新开启了 bug：“房间还亮着”。再次亲眼确认灯泡灭着后，你将情况汇报给了上司。他建议你去地下室检查电线和开关。你抗议说你正直盯盯地看着灯，它就是灭着的。 “我知道，但去检查一下。这样一来你就可以告诉 测试员你确认了所有流程。” 

你叹了口气，前往地下室检查了电线和开关。它们不可能以任何你能理解的方式导电。 你向测试员反馈，你检查了电线和开关，它们不可能通电，你正看着灯泡，它是熄灭的。

“我不是指灯泡，”测试员说。 “bug 里描述的是房间里的光。房间现在仍然不够暗，你应该拉下窗帘。“你回应说窗帘的事不归你管。测试员不相信你说的话，亲自去询问你的领导。

经过一番激烈的讨论之后，他们终于同意将窗帘的问题提交给其他部分去解决，太好了，灯光的问题暂时到此为止了，bug可以顺利地关闭掉了。

现在，CEO突然决定要去18楼会议室开会。你接到通知，要赶去地下室，开启18楼会议室的灯。

你以最快的速度去到了地下室，连上电线，按下开启按钮。回到了办公桌，此时你的手机有了26个未读消息：

“出问题了，灯还是熄灭的！”

“有个问题，灯没有亮。”

“为什么这么久还没有亮灯？”

......

而最新的一条消息则是：“没事了，灯是亮的”。

来自：前端君 web前端教程

链接: https://www.fly63.com/article/detial/1210