程序员最可怕的噩梦是什么？

最糟糕的是，当你不得不从其他人那里接手一个编码/编程项目时，他们不希望其他人看到他们的代码，并且没有对变量使用适当的等式。
我不得不在 Commodore Amiga 上接手一个足球管理游戏，它被称为 Premier Manager 3 Deluxe。最初的程序员出于某种原因离开了这个项目，我不得不在最后一刻进入那里，继续他离开的地方并完成游戏。
问题很快就显现出来了。而不是像这样制作等式：
TeamsinPremierleague = 20
TeamsinFirstDivision = 24
TeamsinSecondDivision = 24
TeamsinThirdDivision = 24
TeamsinConferenceLeague = 20
这很容易理解和不言自明，你只需有一个说“112”的声明。
没有任何参考资料可以告诉您 112 这个数字是如何得出的。最终解决了这个问题，但显然没想到其他人会看到他的代码的原始程序员，为代码中的许多不同功能做了很多次，这意味着改变数据结构（足球管理模拟更接近于数据库比通常的游戏）非常困难，并且可能导致级联效应，其中一个小错误会随着时间的推移累积到一个非常大的错误，这通常会导致系统崩溃！
所以这就是我的噩梦，尽管他还使用了他所有的自定义磁盘制作工具，但仍然设法完成并发布了它……
说真的，在生产支持方面打了一个“坏电话”。避免压力，坚持使用 DevOps（SyOps 的一个不错、安全的幼儿园。哦，等等，请参阅下面的垃圾配置项）。
1. 未付款。
2.项目被取消。
3. 源已丢失的 CI。供应商资不抵债等 SAP 决定“另辟蹊径”以及与操作系统相关的任何事情都失去支持。
4. 编译器或供应商软件中的错误。
5. 法庭命令你的消息来源被曝光。 （德尔格呼吸分析仪代码？）
6. 非建设性的同行批评。
7. 过时和弃用（在 Java 5 中工作）。
8. 在 SE 和 Quora 上发布完全的垃圾，然后被抓住。
9. 丢失源代码（或丢失），或主要 CI（已经发生）。
10. 作为最后一个活着维护系统的人。
11. 发现（多年后）有一种更简单的方法可以做任何事情。
12. 被信任到您交付的产品“未经测试”以节省预算，然后发现需求发生了变化，但不建议更改。尽管签署了用户验收测试，但客户不想支付*任何一张*发票。
13. 未记录的功能。保留文档的供应商（CA，这是你）。
最糟糕的噩梦是丢失了您花费大量时间编写的大部分代码，然后您才意识到必须重新开始。
这发生在我身上，幸运的是我的讲师看到我在做我的项目，但他首先让我汗流浃背，因为截止日期快到了。他说，如果我的一个同学愿意提供一份副本，那么他会除外，但我应该更改代码以使其成为我自己的。我学到了要始终进行备份的教训，而云存储是上天的礼物。