在《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年写道，“只要吸引足够多的眼球，一切漏洞都很浅显。”
没有那句话能像“出错了”一样让程序员/开发者如此沮丧，心里翻江倒海，怒火一点即燃，还要死掉一大片脑细胞。这句生硬的开场白通常标志着让开发者恐惧的长时间排错工作要开始了。
应该还能用
【外评】谷歌：从源头消除内存安全漏洞
【外评】在 RiSC-V 上运行《巫师 3》游戏
【外评】法官驳回大部分 GitHub Copilot 版权索赔要求
谷歌内部推出 SQL 中的管道(Pipe)语法
你们干扰不了我写开源代码
【外评】FreeBSD 将 Rust 纳入基本系统
【外评】电脑从哪里获取时间？
【外评】为什么 Stack Overflow 正在消失？
有时
