当然，262个项目中找到10000个bug其实并不多，平均每个项目只有38个。但是值得注意的是，这些项目的质量差别也很大，有的项目只发现一个bug，而另外一些则包含上百个bug。
无论工程师做了多少枯燥的测试工作，无论他们熬了多少不眠之夜在编程，但最终他们得到的是：会导致软件彻底出问题的 bug。你知道吗，由于软件故障（bug），美国经济每年在浪费生产力、返工和实际毁坏上损失了数十亿美元。
在《Learning From Your Bugs》一文中，我写了关于我是如何追踪我所遇到的一些最有趣的 bug。最近，我回顾了我所有的 194 个条目（从 13 岁开始），看看有什么经验教训是我可以学习的。下面是我总结的最重要的经验教训，包括编码，测试和调试三个方面。
其实没有bug也不准确，因为测试阶段没有发现Bug 并不代表上线以后也没有Bug， 但至少证明这是一段高质量的代码。
一向爽直的 Torvalds 曾猛喷过自己是“越看越不爽”。有趣的是，同样于数月前提交的一些变动，却还没有被审查。XFS 专家 Paul Chinner 自称是系统文件开发者，他在看过代码后说到： 在我试图让你重建补丁却被猛喷之后（正如 Linus 当前认为的那样），我撒手并没再看你们的补丁了。难怪没有其它文件系统维护者愿意把时间浪费在这件破事上面…
去年夏天我写了一些代码来实现从一个哈希表中获取一条消息。这条消息是将要通过另外一个线程放入哈希表中的。这里会有很小的概率发生冲突，即一开始查找消息的时候它还没有被保存进去。
和程序的交互一样，大脑的首要的一个运行特点就是事件驱动（event-driven）机制，也就是说，如果没有事件发生，它几乎不会去做任何事情，而有了事件发生后，大脑就会回应（Respond）它。
影响软件工程进度的原因有很多种，而代码重写无疑是最耗费时间的变更之一。那么重写的时候需要注意哪些细节才能把资源开销控制到最低或可接受的程度呢？
死循环小bug打出生就没见过妈妈。
有人向你反馈了一个bug。 “26楼会议室的灯亮着。它需要被熄灭。”bug的备注里写道“你应该能在5分钟内搞定，只要按一下开关就好了。“ 你去了26楼的会议室。灯的确亮着，但房间里没有灯的开关。
在Bug跟踪系统留下来的绝大部分Bug，就落入了没人管的灰色地带。用户报告的是Bug吗？不完全是。用户在要求新功能或完善某既有功能吗？也不完全是。好吧，那到底是什么？
据悉，每年软件Bug会让美国经济面临近600亿美元的损失。我们都知道，软件Bug很烦人的，会对我们的工作、生活带来很多毁灭性的影响。现在，就让我们按时间顺序来盘点下史上最具有毁灭性的20个软件Bug。
至于开源社区的真谛，开源运动元老埃里克·J·雷蒙德(Eric J. Raymond)所做的阐述也许是最精辟的。他在1997年写道，“只要吸引足够多的眼球，一切漏洞都很浅显。”
没有那句话能像“出错了”一样让程序员/开发者如此沮丧，心里翻江倒海，怒火一点即燃，还要死掉一大片脑细胞。这句生硬的开场白通常标志着让开发者恐惧的长时间排错工作要开始了。
Rust 和 C 文件系统 API
OpenAI 希望收购 Chrome 浏览器，使其成为 "人工智能优先 "的体验
我是如何破解房东的锅炉的
Python 的新 t-strings
OpenAI 为什么要收购 Windsurf？
两年的 Rust 使用感悟
为什么没有像 BitTorrent 这样的 P2P 流媒体协议？
为什么人工智能公司的标志看起来像屁眼？
Fedora 变革的目标是实现 99% 的软件包可重复性
我认识的最好的程序员
