程序员,你会从 Bug 中学习么?

Bug 是绝佳的学习机会。所以我们怎样尽可能多地从修复的 bug 中吸取经验?我至今已经用了 13 年的一个方法是,写下这个 bug 的简单描述、修复方法以及吸取的经验。

遥想 2002 年,我偶然发现一篇描述这个方法的博客(很不幸,我没再找到)。我从那时起就使用这个方法了,并且相信它能帮助我成为一个更出色的程序员。

每当我修复一个特别棘手或有趣的 bug,我总会花几分钟写下一些这个 bug 的信息。这有一个典型记录的例子:

例子

【日期】:2004-08-17

【问题】:当解码 Q.931 信令时无限循环

【原因】:当在Q.931信令中发现一个未知的元素id时,我们试图通过读取它的长度来跳过它,并且将位置指针迁移几个字节。但是,在这个例子中的长度是零,导致我们反复跳过相同的元素id。

【怎么发现的】:在解码一个 Ethereal 从 Nortel 追踪到的安装信息时发现了这个问题。他们的信息是 1016 字节长度(包含大量快速启动元素),但我们的 MSG_MAX_LEN 是 1000。通常我们会收到一条来自 common/Communication.cxx 的信息,但现在,当直接输入需要解析的数据时,数组末端内存访问越界,其恰好是 0,暴露了这个问题。

为了找到它,我仅仅在 9931 解码中添加一些打印输出。但很幸运数据恰好是零。

【修复】:如果长度是零,设置为 1。这方式总是行得通。

【在哪些文件修改了】:
callh/q931_msg.cxx
callh/q931_msg.cxx

【我导致的】:是的

【解决Bug的时间】:1小时

【教训】:信任收到信息中获得的数据。不仅仅是产生大量可能导致问题的数据。显示长度为 0 也同样不好。

实施方式

我有一个命名为 bugs.txt 的纯文本文件。在文件的顶部是一个具备所有标题的模板,但是没有包含信息。当我添加一个新的记录,我复制模板部分,粘贴在模板下面。然后完成记录并且填满信息。大多数展示在上面例子中的 fields 应该是不需要声明的。

有必要指出这并不是 bug 追踪器。我并没有添加所有我修复的 bug 。例如,如果我只是忘记在代码中添加声明,一旦发生这种情况,我就意识到问题出在哪里了,我并不会添加这条记录。仅仅当 bug 本身,或是修复,或是调试过程特别有趣,我才会添加一条新的记录。通常,是我导致了这个 bug。但是偶尔,特别是花几天时间才追踪到的困难 bug,尽管不是我造成的我也会添加一条记录。

一旦修复了一个 bug,我的第一反应是松了口气然后继续前进。我试着一更正后就写下这个记录。这时我的脑海中依然清晰保留所有的细节。拖延会让精确回忆发生的事情变得很困难(或者我压根忘记写下这条记录)。

至今,我已经有 194 条记录,平均每个月有一条新的记录。最重要的是教训部分。这里需要自我反省。是什么导致这个 bug 的特殊性?我发现经验常常来自于三个不同的方面:

编码。我在代码中犯了什么错误?我是否忘记了 else 部分代码?是否系统调用失败,但没有检查 response?我在未来应该怎么调整代码来防止这些问题?

测试。一般不包括本可以在测试中捕获的 bug 。要是这样的话,应该在哪个阶段测试——单元、功能、系统?丢失了哪个测试用例?

调试。我本可以怎样快速定位 bug?我是否使用了正确的方法?我是否假定了太多?我是否需要在代码中使用更好的日志记录?

益处

Nassim Nicholas Taleb 在 《Antifragile》中写到:“错误包含丰富的信息”。我完全同意这个观点。Bug 帮助我们更好地理解系统,告诉我们怎样提高编码、测试和调试技巧。所以我认为尽可能从 bug 中学习经验,是再正常不过的事了。

我发现为每个有趣的 bug 记录下来,让我轻易学习到很多。在记录的行为中我会对发生的事情思考得更深刻。同样,一旦记录下来,我可以在之后检查发生的事情。偶尔,我也会浏览文件,只阅读教训部分,对我认为是从 bug 中学到的最有价值的经验加强记忆。

我记录 bug 文件至今已经有 13 年了。这是一段漫长的时间,但是我坚持下来了,因为作为一名程序员,它帮助我进步。尝试一下吧,看看它是否也对你有益!

打赏支持我翻译更多好文章,谢谢!

打赏译者

打赏支持我翻译更多好文章,谢谢!

任选一种支付方式

4 3 收藏 2 评论

关于作者:Jyy

这个家伙太懒了,只喜欢抽奖。 个人主页 · 我的文章 · 14 ·     

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部