Bug是绝佳的学习机会。所以我们怎样尽可能多地从修复的bug中吸取经验？我至今已经用了13年的一个方法是，写下这个bug的简单描述、修复方法以及吸取的经验。
遥想年，我偶然发现一篇描述如何使用的文章。我从那时起就使用这个方法了，并且相信它能帮助我成为一个更出色的程序员。不过后来我忘记在哪里呢，索性我就写一篇。
每当我修复一个特别棘手或有趣的bug，我总会花几分钟写下一些这个bug的信息。这有一个典型记录的例子：
例子
：-08-17
：当解码Q.信令时无限循环
：当在Q.信令中发现一个未知的元素id时，我们试图通过读取它的长度来跳过它，并且将位置指针迁移几个字节。但是，在这个例子中的长度是零，导致我们反复跳过相同的元素id。
：在解码一个Ethereal从Nortel追踪到的安装信息时发现了这个问题。他们的信息是字节长度（包含大量快速启动元素），但我们的MSG_MAX_LEN是。通常我们会收到一条来自
为了找到它，我仅仅在9解码中添加一些打印输出。但很幸运数据恰好是零。
：如果长度是零，设置为1。这方式总是行得通。
：
callh/q_msg.cxx
callh/q_msg.cxx
：是的
：1小时
：信任收到信息中获得的数据。不仅仅是产生大量可能导致问题的数据。显示长度为0也同样不好。
实施方式
我有一个命名为bugs.txt的纯文本文件。在文件的顶部是一个具备所有标题的模板，但是没有包含信息。当我添加一个新的记录，我复制模板部分，粘贴在模板下面。然后完成记录并且填满信息。大多数展示在上面例子中的fields应该是不需要声明的。
有必要指出这并不是bug追踪器。我并没有添加所有我修复的bug。例如，如果我只是忘记在代码中添加声明，一旦发生这种情况，我就意识到问题出在哪里了，我并不会添加这条记录。仅仅当bug本身，或是修复，或是调试过程特别有趣，我才会添加一条新的记录。通常，是我导致了这个bug。但是偶尔，特别是花几天时间才追踪到的困难bug，尽管不是我造成的我也会添加一条记录。
一旦修复了一个bug，我的第一反应是松了口气然后继续前进。我试着一更正后就写下这个记录。这时我的脑海中依然清晰保留所有的细节。拖延会让精确回忆发生的事情变得很困难（或者我压根忘记写下这条记录）。
至今，我已经有条记录，平均每个月有一条新的记录。最重要的是教训部分。这里需要自我反省。是什么导致这个bug的特殊性？我发现经验常常来自于三个不同的方面：
编码。我在代码中犯了什么错误？我是否忘记了else部分代码？是否系统调用失败，但没有检查response？我在未来应该怎么调整代码来防止这些问题？
测试。一般不包括本可以在测试中捕获的bug。要是这样的话，应该在哪个阶段测试——单元、功能、系统？丢失了哪个测试用例？
调试。我本可以怎样快速定位bug？我是否使用了正确的方法？我是否假定了太多？我是否需要在代码中使用更好的日志记录？
益处
NassimNicholasTaleb在《Antifragile》中写到：“错误包含丰富的信息”。我完全同意这个观点。Bug帮助我们更好地理解系统，告诉我们怎样提高编码、测试和调试技巧。所以我认为尽可能从bug中学习经验，是再正常不过的事了。
我发现为每个有趣的bug记录下来，让我轻易学习到很多。在记录的行为中我会对发生的事情思考得更深刻。同样，一旦记录下来，我可以在之后检查发生的事情。偶尔，我也会浏览文件，只阅读教训部分，对我认为是从bug中学到的最有价值的经验加强记忆。
我记录bug文件至今已经有8年了。这是一段漫长的时间，但是我坚持下来了，因为作为一名合格的程序员，它帮助我进步。尝试一下吧，看看它是否也对你有益！
长按
