标签: bug

和各种诡异 Bug 打交道 13 年,我总结了 18 个经验

和各种诡异 Bug 打交道 13 年,我总结了 18 个经验

最近我重新浏览了这所有的 194 个条目(历时 13 年),看看我从这些 bug 中学到了学到了那些重要的经验教训。我分为编码、测试和调试三大类。

一个小Bug找了6个月,你知道程序员的难了吧

一个小Bug找了6个月,你知道程序员的难了吧

简而言之,我花费了 6 个月的时间去查找一个错误的字母,而它是一个比我多 26 年工作经验的工程师所犯的输入错误。

如何高效且有效的向软件开发人员报告bug

如何高效且有效的向软件开发人员报告bug

如果你真的喜欢某个软件,并且想为其开发者表示感谢,最好的方式之一,就是提交bug报告。下一次当你遇到一个bug的时候,你可以考虑向开发者提交报告。

程序员遇到 Bug 时的 30 个反应,你是哪一种?

程序员遇到 Bug 时的 30 个反应,你是哪一种?

开发应用程序是一个非常有压力的工作。没有人是完美的,因此在这个行业中,代码中出现bug是相当普遍的现象。面对bug,一些程序员会生气,会沮丧,会心烦意乱,甚至会灰心丧气,而另一些程序员会依然保持冷静沉着。因此,如何处理修复bug的过程也值得我们细细琢磨。

C语言中史上最愚蠢的Bug

C语言中史上最愚蠢的Bug

本文来自“The most stupid C bug ever”,很有意思,分享给大家。我相信这样的bug,就算你是高手你也会犯的。你来看看作者犯的这个Bug吧。

惨烈:1 个 Bug, 45 分钟损失 4 亿多美元

惨烈:1 个 Bug, 45 分钟损失 4 亿多美元

2012年8月1日,一个 bug 一步步让骑士资本在交易中损失了 4.65 亿美金,并且直接导致破产。这个故事涉及的代码库,是一个大型、无人维护、腐烂的代码库,代码本身将近 9 年没用过了,真是一次集合了技术债务所有特点的惨案。

一个可笑的小Bug会引起一场大灾难

一个可笑的小Bug会引起一场大灾难

我明白了一个实践教训,即你为什么要将代码中发现的问题报告上去,即使一开始它们看上去那么微不足道。

项目经理叫你去改一个 Bug

项目经理叫你去改一个 Bug

这人懂什么软件工程?你是个艺术家,而芯片就是你的画布。你已经无数次地阅读了《代码整洁之道》,你对它的了解甚至超过了你对自己 GitHub 密码的印象。

我们在各种开源项目中发现的 10000 个 bug

我们在各种开源项目中发现的 10000 个 bug

当然,262个项目中找到10000个bug其实并不多,平均每个项目只有38个。但是值得注意的是,这些项目的质量差别也很大,有的项目只发现一个bug,而另外一些则包含上百个bug。

由软件Bug引发的18次重大事故

由软件Bug引发的18次重大事故

无论工程师做了多少枯燥的测试工作,无论他们熬了多少不眠之夜在编程,但最终他们得到的是:会导致软件彻底出问题的 bug。你知道吗,由于软件故障(bug),美国经济每年在浪费生产力、返工和实际毁坏上损失了数十亿美元。

13年的Bug调试经验总结

13年的Bug调试经验总结

在《Learning From Your Bugs》一文中,我写了关于我是如何追踪我所遇到的一些最有趣的 bug。最近,我回顾了我所有的 194 个条目(从 13 岁开始),看看有什么经验教训是我可以学习的。下面是我总结的最重要的经验教训,包括编码,测试和调试三个方面。

零Bug的代码是怎么炼成的?

零Bug的代码是怎么炼成的?

其实没有bug也不准确,因为测试阶段没有发现Bug 并不代表上线以后也没有Bug, 但至少证明这是一段高质量的代码。

关于JavaScript调试的十来个小技巧

关于JavaScript调试的十来个小技巧

有时候在生产环境下我们发现了一些莫名奇妙的问题,然后忘了把sourcemaps放到这台服务器上,或者在看别人家的网站的源代码的时候,结果就 看到了一坨不知道讲什么的代码,就像下图。Chrome为我们提供了一个很人性化的反压缩工具来增强代码的可读性,大概这么用:

Linus对于Linux内核中潦草的Unix千年虫bug补丁感到很不爽

Linus对于Linux内核中潦草的Unix千年虫bug补丁感到很不爽

一向爽直的 Torvalds 曾猛喷过自己是“越看越不爽”。有趣的是,同样于数月前提交的一些变动,却还没有被审查。XFS 专家 Paul Chinner 自称是系统文件开发者,他在看过代码后说到: 在我试图让你重建补丁却被猛喷之后(正如 Linus 当前认为的那样),我撒手并没再看你们的补丁了。难怪没有其它文件系统维护者愿意把时间浪费在这件破事上面…

记一次灵异般的 Bug 调试经历

记一次灵异般的 Bug 调试经历

说到程序员的噩梦,除了《程序员的 13 种噩梦,你遇到过哪些?》这篇提到的「无法重现的 Bug」,还有「遇到一个不懂技术又是掌控狂的项目经理」或「频繁变更需求」。自称有 35 年编程经历的 Mick Stute 对最大的噩梦有不同的体验。来看看他在 Quora 上拿到 16k 多顶的经历:

当cpu飙升时,找出php中可能有问题的代码行

当cpu飙升时,找出php中可能有问题的代码行

当你发现一个平时占用cpu比较少的进程突然间占用cpu接近100%时,你如何找到导致cpu飙升的原因?我的思路是,首先找到进程正在执行的代码行,从而确定可能有问题的代码段。然后,再仔细分析有问题的代码段,从而找出原因。

程序员遇到Bug时的30个反应

程序员遇到Bug时的30个反应

开发应用程序是一个非常有压力的工作。没有人是完美的,因此在这个行业中,代码中出现 bug 是相当普遍的现象。面对 bug,一些程序员会生气,会沮丧,会心烦意乱,甚至会灰心丧气,而另一些程序员会依然保持冷静沉着。因此,如何处理修复 bug 的过程也值得我们细细琢磨。

MacTalk:怎么减少编程中的bug?

MacTalk:怎么减少编程中的bug?

为什么要编程?因为代码没在那里。创造一个世界是如此让人着迷,Linux 的创始者 Linus 这样表述对编程的喜爱之情:

软件bug的规律

软件bug的规律

一般地,在程序代码中犯错比不犯错更容易
不管看起来是否违反直觉,我觉得存在一种半正式的论据。在同样心态下,也有一些有趣的推论。

那些臭名昭著的软件bug,史上留名的有哪些?

那些臭名昭著的软件bug,史上留名的有哪些?

在现今数字年代,计算机bug不但困扰着每个程序员,更会无可避免影响我们的生活,小到每个人的衣食住行,大到国家经济,世界局势。随着我们的生活方式渐渐的数字化、互联网化,数字世界的找虫和杀虫就变得越来越重要。

拒绝修复bug的几个正当理由

拒绝修复bug的几个正当理由

 当某些功能没有按预期运行时,bug 就出现了。一次 bug 修复基本上是给现有代码打一个补丁,它应该解决当前问题,以确保「该功能」按预期运行。

每行代码都有潜在的 bug

每行代码都有潜在的 bug

去年夏天我写了一些代码来实现从一个哈希表中获取一条消息。这条消息是将要通过另外一个线程放入哈希表中的。这里会有很小的概率发生冲突,即一开始查找消息的时候它还没有被保存进去。

大脑如同编程,bug如何修复?

大脑如同编程,bug如何修复?

和程序的交互一样,大脑的首要的一个运行特点就是事件驱动(event-driven)机制,也就是说,如果没有事件发生,它几乎不会去做任何事情,而有了事件发生后,大脑就会回应(Respond)它。

如何避免软件工程中最昂贵错误的发生

如何避免软件工程中最昂贵错误的发生

影响软件工程进度的原因有很多种,而代码重写无疑是最耗费时间的变更之一。那么重写的时候需要注意哪些细节才能把资源开销控制到最低或可接受的程度呢?

小bug找妈妈

小bug找妈妈

死循环小bug打出生就没见过妈妈。