//我是一名前端开发者，但我想这个故事会引起任何开发者的共鸣。有人向您报告了一个错误。“26楼会议室灯亮着，需要关掉。”错误说明上写着“你应该能够在5分钟内完成，只需轻按一下开关。”你去26楼的会议室。灯确实是亮着的，但房间里没有电灯开关。因此，您已准备好安装一个。但设计师说它会破坏房间的美感。此外，墙壁是混凝土的。您需要合适的工具来安装交换机。但是，没有人会批准购买这些工具。如果没有合适的工具，安装开关可能需要两天时间。他们希望您立即关灯，因为他们担心CEO可能会心血来潮决定走到26楼，然后路过会议室问为什么灯亮着。现在您不断收到电子邮件询问为什么会议室的灯还亮着。现在你必须发送大量电子邮件来解释情况，一些人会开始恐慌电子邮件链。您知道，如果您希望通过电子邮件讨论解决问题（而不实际采取行动），那么问题将永远无法解决。在bug系统中，这个bug是你来处理的，截止日期是今天。问题不解决，麻烦的是你。于是，你设法钻进了26楼走廊的天花板，找到了会议室灯的电线，并将其剪断。问题已经解决了。为了平息电子邮件链中的恐慌，您（再次发送电子邮件）解释了您是如何解决问题的。邮箱里静了一会儿。一亮又一亮，大家都很着急，现在会议室的灯都开不了关了。如果CEO想在那里开会怎么办？所以他们要求你“把电线接到地下室”。当有人需要开灯时，他们会通知您下到地下室并连接或断开电线。你抗议这个荒谬的解决方案。你的老板说，“是的，我知道这并不理想。但这是目前唯一的解决方案。”此时，你面临一个选择。你可以按照他们说的去做，或者辞职以示抗议并另谋高就。但是你知道，一旦你开始一份新工作，新工作可能会要求你做一些像那样愚蠢的事情，如果不是更愚蠢的话。你把电线从26层拉到地下室。当你走进地下室发现墙上已经挂着几十根电线时，你就会知道你并不孤单，而且你知道这个愚蠢的想法从何而来。你调整了电线，尽可能地给它贴上标签，然后默默地向下一个可能需要处理它的伙伴道歉。最后，您回到自己的办公桌前，并且有了一份新报告。QA重新打开了该错误。错误描述说“房间仍然亮着”。你回到26楼的会议室。灯灭了。你回到你的办公桌，关闭这个错误，并注意到你自己检查了它。QA再次重新打开了该错误。“房间还亮着”坚持错误描述。在亲眼确认灯泡再次熄灭后，你将情况报告给了老板。他建议您检查地下室的电线。你抗议说你正直视着那盏灯，但它已经熄灭了。“我知道，不过你去看看吧，这样你就可以告诉QA你确认了所有流程。”你叹了口气，走向地下室。果然，电线没有接好，剪口的两端都包好了。他们不可能以任何你能理解的方式导电。你反馈给QA，你检查电线，它们没有连接，你正在看灯泡，它已关闭。“我不是指灯泡，”QA说。“虫子正在描述房间里的光线。房间还不够暗。你应该把百叶窗拉下来。”你回答说百叶窗不在你的控制范围内，错误正在描述灯光。QA不相信你，发送了一组电子邮件询问错误是否包括被拉下的百叶窗。你等了一会，邮箱又响了。“理论上，”他们问道，“如果光线太亮或太暗，在26楼会议室开会的人是否可以随意拉上或拉??上百叶窗？”是的，他们可以，你回答。“正常人都能做到吗？他们不需要你去做吗？”是的，任何一个正常人。不，他们不需要你。任何人都可以做到这一点。“太好了。好吧，现在照明问题就这些了。我会安排一个会议来讨论如何处理百叶窗。”错误已关闭。现在，CEO可能从所有关于26楼会议室的讨论中感觉到了什么，想在那里开会。您会收到几封恐慌的电子邮件，希望开灯。你去地下室，接上电线，然后回到你的办公桌前。您的收件箱中有32封新邮件。“出了点问题——灯还没亮！”“有问题——不亮！”“你收到我们的电子邮件了吗？等等，等等。第32封电子邮件说，“没关系-灯亮了。“这个（指的是32封电子邮件）过程或多或少会随着灯的开关而重复。如果说有什么好消息的话，那就是开完会大家都忘记了26楼还有一个会议室，你什么都不用做。
