@Livid 不理解，这发的是个专业内容，不是推广，为什么移动到推广节点呢？

@lovestudykid 大活人写的，天王盖地虎，小鸡炖蘑菇，琼浆玉液酒，一百八一杯……

@sillydaddy 哎不知道选哪个节点，没有质量与测试相关的节点，一般大家会发到哪里呢？

@Chinsung 是的，盲测其实最有效，最能反应程序的健壮性。测试人员太了解业务细节了就容易失去用户视角，往一些刁钻的方向去思考，但用户其实根本不会这样使用软件。

@jones2000 咱就是说，有没有可能，架构打一生出来就是注定要腐化的。。讽刺的是要缩减预算了也往往从测试部门下手。

@codefever 是的 ，有时候越新来的越能发现问题，老人都思维定势了。

@akakidz 单纯分享故事，不是推广

@linghutf 可持续变现的其他技能，不受物理场地影响的，最好学习成本和投资成本都低的……

再提个问，副业是不是就得选择自己喜欢的事情了？毕竟有可能作为终身的营生。尴尬的事自己喜欢的事情往往没经济收益。

@jaoyina 确实，这也是一种自然筛选……

@kingjpa 尝试总结一下，谋求发展似乎有以下几条路径可走：

1. 技术转管理：持续不断的花样卷，削尖脑袋往上钻。（中层夹板气最难）
2. 追求技术卓越：在技术道路上越走越远，一条道走到黑。（追求单纯省心的首选）
3. 收入多元化：不把鸡蛋放在一个篮子里，要工作也要副业，可投资理财、尝试其他项目等。（都可尝试）
4. 追求自由职业：为自己打工，自负盈亏。（当副业收入>主业时可考虑 all in 副业）

其中 1 和 2 互斥，3 和 4 可坚持与 1 或 2 并行。方案：134 → 34 ，or 234 → 34

@nigulasida 为老板打工当然是这样咯，为自己打工是正解。问题是，怎样才算为自己打工呢？

@darkengine 是滴，不懂就问，分享文章限制时效么？感觉 2021 年不算旧文，就分享了。

亲们，我想把这个帖子改造成“匪夷所思的奇怪 bug 合集”~ 大家没事可以来翻翻这些诡异的 bug ，为 coding 时光添加一些乐趣~~~



原文 link: https://www.quora.com/Programming-Interviews/Whats-the-hardest-bug-youve-debugged/answer/Dave-Baggett

翻译转自知乎： https://www.zhihu.com/question/22108128

补充故事：

“这是我全部编程生涯中，唯一一次因为量子力学 debug 的问题”这篇文章中，怎么体现了量子力学？
回想起这个 bug ，仍然让我有些痛苦。作为一个程序员，在发现 bug 时，你学会了首先在自己代码中找问题，或许在测试一万次之后，你会把问题归咎于编译器。只有在这所有的都不起作用之后，你才会把问题归咎于硬件。

这是我遭遇一个硬件 bug 的故事。

抛开别的不说，我曾为《 Crash Bandicoot 》写存储卡（读写）代码。对于一个自大的游戏程序员，这就像是在公园里散步一样轻松愉快，我认为只要几天就写完了。我中止调试六个礼拜。在此期间我做一些其他的事情，但我一直回来处理这个 bug几天内每天几个小时。这个 bug 实在烦人。

这个 bug 的症状是，当你需要保存你的进度时，代码会访问存储卡，而大部分情况下没有什么问题…但是偶尔读写会超时…没有任何明显的原因。一个短小的写入经常毁掉存储卡。玩家要保存进度，我们不仅不保存，还擦除他们存储卡上的全部东西。天哪。

过了一段时间，我们在 Sony 的制作人 Connie Booth 慌了。我们显然不能带着这个 bug 发布游戏，而六个星期之后我对于问题出在哪一点线索都没有。通过 Connie 我们向其他 PS1 开发者求助：有没有人出现过像我们这样的情况？没有。绝对没有任何人在存储卡系统上出现任何问题。

在你绞尽脑汁之后，你能做的唯一一个调试方法就是分而治之：一点点去除程序中的代码，直到留下的代码很少但你仍然出问题。像木雕一样去除没有问题的代码，留下的就是你的 bug 所在。

在这样的背景下挑战在于，视频游戏是很难去除某一部分的。在你删除模拟重力或者显示字符的代码后，如何运行游戏？

你必须做的是用一个假装做真正的事情，但实际上只是做很简单的不会出现 bug 事情的东西来替换掉整个模块。你必须写新的支撑代码来让这些玩意正常工作。这是一个缓慢而痛苦的过程。

长话短说：我做完了。我移除了大片大片的代码，相当多，只留下了初始化代码就是准备游戏运行系统，初始化底层硬件等等。当然，我不能显示加载 /保存菜单，因为我截除了所有的图像代码。但是我能够假装用户使用（不可见的）加载 /保存屏幕并且请求保存，然后写入卡中。

我最终以一个带有这个 bug 的很少量的代码结束但问题仍然随机出现！在大多数情况下没啥问题，但是偶尔会失效。基本上所有的 Crash 的实际代码都被移除了，但还是这样。这实在是莫名其妙：留下来的代码基本上都没做什么事。

在那时估计是凌晨 3 点一个想法蹦了出来。读写（ I/O ）涉及精确定时。无论是硬盘、存储卡、蓝牙发送器随便啥做读写的底层代码都是根据时钟来的。

时钟让不直接连接到 CPU 的硬件设备和 cpu 运行的代码同步。时钟决定了波特率数据从一头传到另一头的速率。如果计时有什么问题，硬件或者软件或者两者都会乱七八糟的。这真的，真的很糟糕，并且通常导致数据损坏。

如果我们的初始化代码以某种方式弄乱了计时会怎么样？我又看了一遍测试程序中和计时有关的代码，并注意到我们将 PS1 上的可编程计时器设置到了 1kHz （ 1000 跳每秒）。这是比较快了，当 PS1 启动的时候，默认状态大概是 100Hz 。因此，大多数游戏将他们的计时器设置为 100Hz 。

这个游戏的带头（和除我外的唯一）开发者 Andy ，将计时器设置为 1kHz ，使得 Crash 的动作计算更加准确。Andy 喜欢矫枉过正，如果我们要模拟重力，我们应该尽可能的提高精度！

然而如果提高计时器频率莫名其妙的干扰了整个程序的计时，故而将这个计时器设置到存储卡的波特率上会怎样呢？

我将计时器代码注释掉。然后我就无法复原这个 bug 了。但是这并不表示 bug 被修复了，这个问题是随机发生的。万一我只是运气好呢？

几天过去了，我还是在玩我的测试程序。Bug 没有再出现。我回到全部的 Crash 代码中，修改了加载 /保存代码，在访问存储卡之前将可编程计时器重置为默认设置（ 100Hz ），之后设置回 1kHz 。从此之后没有发现问题再次出现。

但是…为什么？

我重新回到测试程序上，试着检测当计时器设置为 1kHz 时出现的那些错误的模式。终于，我注意到这些错误出现在使用 PS1 手柄的人身上。因为我自己很少这样做，所以我没有注意到（为啥我要在测试加载 /保存代码的时候用手柄）。但是有一天我们的美工等我去完成测试（我确定那时候我在爆粗口），而他紧张的摆弄着手柄。卡损坏了。“等下，怎么回事？喂，再来一次！”

一旦我发现了这两件事是联系着的，就很容易重现 bug：开始写入存储卡，动一下手柄，存储卡损坏。在我看来完全是硬件 bug 。

我去找 Connie 告诉他我的发现。她转述给设计过 PS1 的硬件工程师。她被告知：“不可能，这不可能是硬件问题。”我跟她说问一下我能不能直接和他说。

那个工程师给我打电话了，他用着他的烂英语，我用着我更烂的日语，我们争论一会。我最后说：“我给你一个 30 行的测试程序，让你在动手柄的时候能够出现这问题。”他答应了。他向我保证，这是浪费时间，而他正在一个新项目上很忙，但因为我们是 Sony 很重要的开发者，他会试的。

第二天晚上（我们在洛杉矶，而他在东京，所以对于我来说是晚上而他是到了第二天），他给我打电话，不好意思的向我道歉。这是个硬件问题。

我还是没有完全搞清楚问题到底在哪，但是我的印象中，从 Sony 总部的反馈听到的是，如果将可编程计时器设置到足够高的时钟频率，会影响到主板上时钟晶振附近的一些东西。这些东西之一就是存储卡的波特率控制器，同时也设置手柄的波特率。我不是搞硬件的，所以对于细节我相当模糊。

但是主旨是主板上两个独立部分的串扰，以及手柄接口和存储卡接口数据发送的结合在 1kHz 的时钟频率下会导致丢位，从而数据丢失，以致卡损坏。

这是我全部编程生涯中，唯一一次因为量子力学 debug 的问题。

讨论很热烈啊，再赠送两个小故事，是我公众号的留言回复，当时看到也是惊了，“事出反常必有妖”系列。

故事 1：听过一个邮件服务器的故事，这个公司的邮箱经常发不出去邮件，也不是都发不出去，有时候也能发出去
后来统计了发出去的邮件，发现接收服务器都在 300 公里范围内。追查结果是，邮箱发送超时的设置，应该 1 秒，工程师随手写了 1 ，但是默认单位是毫秒，1 毫秒电信号只能传播 300 公里。

故事 2：还听过某医院的故事，每天早上七点到七点半之间，重症监护病房，最门口那个床的病人特别容易死亡，就这个点，就这个病床，谁住这个床谁倒霉，别的时间别的病人都没事。医生怀疑门口漏风，怀疑气温变化，查了很久。后来发现，早上七点，清洁工进来打扫卫生，把门口的电源拔了，插吸尘器。

@HeyWeGo 感谢反馈，我找一下原 PO 添加引用。

分享一个我经历过的 bug ，那还是一个原始的 ASP 页面，我把树状结构的某个父节点上的叶子挪到另一个父节点上，怎么挪都挪不过去，刚拽出来叶子就丢了，但开发每次挪都能挪过去。我们分析了半天，对比数据、机器、配置等等，后来发现是我拖拽的太快了，在操作快速的情况下叶子找不到新父节点就丢了，开发每次都慢慢挪（一个慢性子），所以从来没遇到过这个 bug~

@McreeWu 如果基于软件产品的生命周期来看会容易理解一些，在 0-1 阶段，需要快速验证产品构想，尽量快速获客争取留存，这是没问题的。但如果定义不清，或者过了这个阶段，可能该好好打磨产品功能了，却还在做这样急功近利的事情，就会流失用户了。这似乎是个悖论，为了快速变现而不会产出有价值的产品去长久的变现。

@fredli 是，确实 toB 似乎没有 toC 更关注“用户”体验，用户在这里没有不用的权利。