又到了一年中可以穿上盛装讲恐怖故事的时候，那就是万圣节。为了纪念这一年中最恐怖的夜晚，我们决定分享恐怖的 dev 故事。毕竟，这些故事比僵尸更可怕，希望它们能起到警示作用…
在询问和接触我们的一些客户（以及我们自己的开发人员）告诉我们他们令人毛骨悚然的故事后，发现编程并不是人们所说的那样，很多陷阱、灾难和悲观的故事，都是为了抓住机会。
1.“哦，我刚才删除了一些内容”
这是个经典操作。你从未经历过心脏病发作，就像在没经历过意外删除一样。不幸的是这经常发生。这是丹尼的故事，你可能也有类似的故事：
“我单击[是]，就把不应该删除的内容删掉了，我删了当前正在使用的一个流行功能。从备份中恢复要花几个小时，更不用说给支持部门挖的坑了。”
2.“为什么我要处理这个遗留代码？”
在恐怖故事中，似乎每个人都会列出遗留代码。虽然“遗留代码”一词有不同的含义，包括外包代码、复杂代码、过时代码、别人的代码等等，但它们貌似都有一个负面含义。
罗恩用他的传统代码描述了他的经验：
“我被分配到一个实时引擎的 infra 团队，infra 代码是一个 15 年前的 ansic C，里面充满了宏（其中一些宏生成了其他宏）。本来要训练我的人，却让我去处理代码，他说：‘这是代码，用这个脚本编译它，在这里添加调试断点。祝你好运，今天是我在这里的最后一天。’我必须自己从头开始学习。我哭了一个星期。”
3.“打印日志-什么F？？？”
日志足够令人沮丧，因为它不必打印，就好像你生活在石器时代（并传真道-我不骗你）。罗伊就是这样的：
“有一次，我们遇到了一位非常注重安全的客户。我们不被允许访问发生问题的机器，不能从该机器截图或文件。最终解决方案是打印日志文件和传真把他们交给我们。”
4.合并失败
正如 Dave 说的，删别人的代码让人难受：
“我和团队中的另一个开发人员在同一个模块上工作。他提交了他的代码，但我要提交我的代码时，我没有合并，而是把他的更改删除了。我还是选择告诉他发生了什么，最后我们设法恢复了他的变化，但他对我的看法从来没有变过。”
5.“我不是按了‘保存’吗？”
你拼命工作却忘了按“保存”？汤米分享了他的恐怖拯救故事：
“我只是忘了按‘保存’按钮，所有的工作都白干了。当时注意力分散了下，我犯了一个错误，啥都没了。我不得不重写代码，花了几个小时。幸亏没人发现。”
6安全漏洞
安全漏洞非常令人不快。诚然，还有更糟糕的由于人为错误而泄露用户私人信息的安全漏洞的故事，但幸运的是，这个故事有点轻描淡写：
“我提交了一个代码，该代码负责身份验证机制中的安全性，该机制允许未经授权的管理员对应用程序拥有特权。我们很快修复了它，但仍有未经授权的应用程序条目。”
7.昂贵的 Bug
Bug 和特性一样常见。如果有一个功能，很可能有不止一个 bug。然而，有些错误比其他错误更严重，尤其是如果你在金融机构工作，比如 Michel：
“我在一家大银行工作。我发布了一个有 bug 的功能。没什么大不了的，对吧？错了！那个特定的错误代表，在修复之前要损失数千美元。虽然咱们团队 QA 的职责是找出它，但我还是感到羞愧。”
8. 地狱升级
升级很麻烦，并不总是平稳。Ran 解释道：
“我的代码依赖于某个库。那家图书馆有更新所以我不得不更新，结果却不太好。一切都卡住了，我花了很长时间才正确更新库。”
9.GitHub 惨败
显然，这种情况经常发生：将公司的证书上传到 GitHub.只需搜索 “GitHub 上传的凭证/密码”，你就会发现各种有趣的例子。如果你觉得很好笑，罗比在他身上发生这事的时候并没有笑：“我不小心把公司的证书上传到 GitHub.但我们并不能保证它肯定不会泄漏出去，后来出事就尴尬了。”
10.我们最喜欢的：编译错误
虽然编译时间总是休息的好时机，但当时间紧迫时，等待 40 分钟来完成构建过程，只是为了看到在某个地方的头文件中忘记了分号（；）可能会让你发疯。如果你在运行夜间构建，情况就更不好说了。下面是吉米的故事：
“整个团队日以继夜地工作。我们在服务器内部发现了一些不好的东西。这时候必须提交更改，并等待构建完成很多次，然后才能成功。我们花了一整天的时间在上面，只是因为我们每次都要等待构建完成，而且花了 2 个小时。简直是噩梦！”
经验教训
希望这些故事会铭刻在你的记忆中，这样你就会永远记得有一个备用计划。当狗屎击中风扇，你删除一个功能，上传密码到GitHub，或其他什么-你最好准备好！你只有在灾难中恢复的能力才是最好的。
你有自己的故事想和大家分享吗？用 #devhorrorstory 在社交网站标记并@我们（@incredibuild）。
在此之前，万圣节快乐！
