程序员修复一个bug的心路历程，太形象了
和你们一样，我也是一个普普通通的前端开发者，在日常工作中，大部分时间不是在写新代码，而是在改代码，或是需求被改了，或是报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个未读消息：
“出问题了，灯还是熄灭的！”
“有个问题，灯没有亮。”
“为什么这么久还没有亮灯？”
......
而最新的一条消息则是：“没事了，灯是亮的”。
热门文章
原创教程
原创教程：《ECMAScript 6 教程》
附加习题：《ECMAScript 6 教程》测试题
原创教程：《Vue2.0基础教程》
原创教程：《Vue2.0进阶教程》
附加习题：《Vue2.0基础教程》测试题
趣味职场
职场感悟：混口饭吃，谈不上喜欢
职场焦虑：程序员回三四线城市能干啥？
感到迷茫：我很努力，但依然很迷茫
薪资待遇：那么点工资，能招到人吗？
培训出身：我是一个培训出身的程序员
培训费用：花1.8万参加前端培训，值吗？
培训简历：简历包装成1-2年经验，咋办？
搞笑黑话：互联网公司黑话，搞笑到爆
职业自由：程序员职业自由的6个阶段
职场形象：在别人眼里，程序员是这样的
合作推广分割线
