十月初的时候我在贝洛奥里藏特的巴西 Python 大会上做了主题演讲。这是稍加改动过的演讲文稿。你可以在这里观看演讲视频。
我爱 bug
我目前是 Pilot.com 的一位高级工程师，负责给创业公司提供自动记账服务。在此之前，我曾是 Dropbox 的桌面客户端组的成员，我今天将分享关于我当时工作的一些故事。更早之前，我是 Recurse Center 的导师，给身在纽约的程序员提供临时的训练环境。在成为工程师之前，我在大学攻读天体物理学并在金融界工作过几年。
但这些都不重要——关于我你唯一需要知道的是，我爱 bug。我爱 bug 因为它们有趣。它们富有戏剧性。调试一个好的 bug 的过程可以非常迂回曲折。一个好的 bug 像是一个有趣的笑话或者或者谜语——你期望看到某种结果，但却事与愿违。
在这个演讲中我会给你们讲一些我曾经热爱过的 bug，解释为什么我如此爱 bug，然后说服你们也同样去热爱 bug。
Bug 1 号
好，让我们直接来看第一个 bug。这是我在 Dropbox 工作时遇到的一个 bug。你们或许听说过，Dropbox 是一个将你的文件从一个电脑上同步到云端和其他电脑上的应用。
+--------------+ +---------------+ | | | | | 元数据服务器 | | 块服务器 | | | | | +-+--+---------+ +---------+-----+ ^ | ^ | | | | | +----------+ | | +---> | | | | | 客户端 +--------+ +--------+ | +----------+
这是个极度简化的 Dropbox 架构图。桌面客户端在你的电脑本地运行，监听文件系统的变动。当它检测到文件改动时，它读取改变的文件，并把它的内容 hash 成 4 MB 大小的文件块。这些文件块被存放在后端一个叫做块服务器的巨大的键值对数据库中。
当然，我们想避免多次上传同一个文件块。可以想见，如果你在编写一份文档，你应该大部分时候都在改动文档最底部——我们不想一遍又一遍地上传开头部分。所以在上传文件块到块服务器之前之前，客户端会先和一个负责管理元数据和权限等等的服务器沟通。客户端会询问这个元数据服务器它是需要这个文件块，还是已经见过这个文件块了。元数据服务器会返回每一个文件块是否需要上传。
所以这些请求和响应看上去大概是这样：客户端说“我有一个改动过的文件，分为这些文件块，它们的 hash 是 'abcd,deef,efgh'。服务器响应说“我有前两块，但需要你上传第三块”。然后客户端会把那个文件块上传到块服务器。
+--------------+ +---------------+ | | | | | 元数据服务器 | | 块服务器 | | | | | +-+--+---------+ +---------+-----+ ^ | ^ | | '有, 有, 无' | 'abcd,deef,efgh' | | +----------+ | efgh: [内容] | +---> | | | | | 客户端 +--------+ +--------+ | +----------+
这是问题的背景。下面是 bug。
+--------------+ | | | 块服务器 | | | +-+--+---------+ ^ | | | '???' 'abcdldeef,efgh' | | +----------+ ^ | +---> | | ^ | | 客户端 + +--------+ | +----------+
有时候客户端会提交一个奇怪的请求：每个 hash 值应该包含 16 个字母，但它却发送了 33 个字母——所需数量的两倍加一。服务器不知道该怎么处理它，于是会抛出一个异常。我们收到这个异常的报告，于是去查看客户端的记录文件，然后会看到非常奇怪的事情——客户端的本地数据库损坏了，或者 python 抛出 MemoryError，没有一个合乎情理的。
如果你以前没见过这个问题，可能会觉得毫无头绪。但当你见过一次之后，你以后每次看到都能轻松地认出它来。给你一个提示：在那些 33 个字母的字符串中，l 经常会代替逗号出现。其他经常出现的字符是：
l \x0c < $ ( . -
英文逗号的 ASCII 码是 44。l 的 ASCII 码是 108。它们的二进制表示如下：
bin(ord(',')): 0101100
bin(ord('l')): 1101100
你会注意到 l 和逗号只差了一位。问题就出在这里：发生了位反转。桌面客户端使用的内存中的一位发生了错误，于是客户端开始向服务器发送错误的请求。
这是其他经常代替逗号出现的字符的 ASCII 码：
, : 0101100 l : 1101100 \x0c : 0001100 < : 0111100 $ : 0100100 ( : 0101000 . : 0101110 - : 0101101
位反转是真的！
我爱这个 bug 因为它证明了位反转是可能真实发生的事情，而不只是一个理论上的问题。实际上，它在某些情况下会比平时更容易发生。其中一种情况是用户使用的是低配或者老旧的硬件，而运行 Dropbox 的电脑很多都是这样。另外一种会造成很多位反转的地方是外太空——在太空中没有大气层来保护你的内存不受高能粒子和辐射的影响，所以位反转会十分常见。
你大概非常在乎在宇宙中运行的程序的正确性——你的代码或许事关国际空间站中宇航员的性命，但即使没有那么重要，也还要考虑到在宇宙中很难进行软件更新。如果你的确需要让你的程序能够处理位反转，有很多硬件和软件措施可供你选择，Katie Betchold 还关于这个问题做过一个非常有意思的讲座。
在刚才那种情况下，Dropbox 并不需要处理位反转。出现内存损坏的是用户的电脑，所以即使我们可以检测到逗号字符的位反转，但如果这发生在其他字符上我们就不一定能检测到了，而且如果从硬盘中读取的文件本身发生了位反转，那我们根本无从得知。我们能改进的地方很少，于是我们决定无视这个异常并继续程序的运行。这种 bug 一般都会在客户端重启之后自动解决。
不常见的 bug 并非不可能发生
这是我最喜欢的 bug 之一，有几个原因。第一，它提醒我注意不常见和不可能之间的区别。当规模足够大的时候，不常见的现象会以值得注意的频率发生。
覆盖面广的 bug
这个 bug 第二个让我喜欢的地方是它覆盖面非常广。每当桌面客户端和服务器交流的时候，这个 bug 都可能悄然出现，而这可能会发生在系统里很多不同的端点和组件当中。这意味着许多不同的 Dropbox 工程师会看到这个 bug 的各种版本。你第一次看到它的时候，你 真的 会满头雾水，但在那之后诊断这个 bug 就变得很容易了，而调查过程也非常简短：你只需找到中间的字母，看它是不是个 l。
文化差异
这个 bug 的一个有趣的副作用是它展示了服务器组和客户端组之间的文化差异。有时候这个 bug 会被服务器组的成员发现并展开调查。如果你的 服务器 上发生了位反转，那应该不是个偶然——这很可能是内存损坏，你需要找到受影响的主机并尽快把它从集群中移除，不然就会有损坏大量用户数据的风险。这是个事故，而你必须迅速做出反应。但如果是用户的电脑在破坏数据，你并没有什么可以做的。
分享你的 bug
如果你在调试一个难搞的 bug，特别是在大型系统中，不要忘记跟别人讨论。也许你的同事以前就遇到过类似的 bug。若是如此，你可能会节省很多时间。就算他们没有见过，也不要忘记在你解决了问题之后告诉他们解决方法——写下来或者在组会中分享。这样下次你们组遇到类似的问题时，你们都会早有准备。
Bug 如何帮助你进步
Recurse Center
在加入 Dropbox 之前，我曾在 Recurse Center 工作。它的理念是建立一个社区让正在自学的程序员们聚到一起来提高能力。这就是 Recurse Center 的全部了：我们没有大纲、作业、截止日期等等。唯一的前提条件是我们都想要成为更好的程序员。参与者中有的人有计算机学位但对自己的实际编程能力不够自信，有的人已经写了十年 Java 但想学 Clojure 或者 Haskell，还有各式各样有着其他的背景的参与者。
我在那里是一位导师，帮助人们更好地利用这个自由的环境，并参考我们从以前的参与者那里学到的东西来提供指导。所以我的同事们和我本人都非常热衷于寻找对成年自学者最有帮助的学习方法。
刻意练习
在学习方法这个领域有很多不同的研究，其中我觉得最有意思的研究之一是刻意练习的概念。刻意练习理论意在解释专业人士和业余爱好者的表现的差距。它的基本思想是如果你只看内在的特征——不论先天与否——它们都无法非常好地解释这种差距。于是研究者们，包括最初的 Ericsson、Krampe 和 Tesch-Romer，开始寻找能够解释这种差距的理论。他们最终的答案是在刻意练习上所花的时间。
他们给刻意练习的定义非常精确：不是为了收入而工作，也不是为了乐趣而玩耍。你必须尽自己能力的极限，去做一个和你的水平相称的任务（不能太简单导致你学不到东西，也不能太难导致你无法取得任何进展）。你还需要获得即时的反馈，知道自己是否做得正确。
这非常令人兴奋，因为这是一套能够用来建立专业技能的系统。但难点在于对于程序员来说这些建议非常难以实施。你很难知道你是否处在自己能力的极限。也很少有即时的反馈帮助你改进——有时候你能得到任何反馈都已经算是很幸运了，还有时候你需要等几个月才能得到反馈。对于在 REPL 中做的简单的事情你可以很快地得到反馈，但如果你在做一个设计上的决定或者技术上的选择，你在很长一段时间里都无法得到反馈。
但是在有一类编程工作中刻意练习是非常有用的，它就是 debug。如果你写了一份代码，那么当时你是理解这份代码是如何工作的。但你的代码有 bug，所以你的理解并不完全正确。根据定义来说，你正处在你理解能力的极限上——这很好！你马上要学到新东西了。如果你可以重现这个 bug，那么这是个宝贵的机会，你可以获得即时的反馈，知道自己的修改是否正确。
像这样的 bug 也许能让你学到关于你的程序的一些小知识，但你也可能会学到一些关于运行你的代码的系统的一些更复杂的知识。我接下来要讲一个关于这种 bug 的故事。
Bug 2 号
这也是我在 Dropbox 工作时遇到的 bug。当时我正在调查为什么有些桌面客户端没有像我们预期的那样持续发送日志。我开始调查客户端的日志系统并且发现了很多有意思的 bug。我会挑一些跟这个故事有关的 bug 来讲。
和之前一样，这是一个非常简化的系统架构。
+--------------+ | | +---+ +----------> | 日志服务器 | |日志| | | | +---+ | +------+-------+ | | +-----+----+ | 200 ok | | | | 客户端 | <-----------+ | | +-----+----+ ^ +--------+--------+--------+ | ^ ^ | +--+--+ +--+--+ +--+--+ +--+--+ | 日志 | | 日志 | | 日志 | | 日志 | | | | | | | | | | | | | | | | | +-----+ +-----+ +-----+ +-----+
桌面客户端会生成日志。这些日志会被压缩、加密并写入硬盘。然后客户端会间歇性地把它们发送给服务器。客户端从硬盘读取日志并发送给日志服务器。服务器会将它解码并存储，然后返回 200。
如果客户端无法连接到日志服务器，它不会让日志目录无限地增长。超过一定大小之后，它会开始删除日志来让目录大小不超过一个最大值。
最初的两个 bug 本身并不严重。第一个 bug 是桌面客户端向服务器发送日志时会从最早的日志而不是最新的日志开始。这并不是很好——比如服务器会在客户端报告异常的时候让客户端发送日志，所以你可能最在乎的是刚刚生成的日志而不是在硬盘上的最早的日志。
第二个 bug 和第一个相似：如果日志目录的大小达到了上限，客户端会从最新的日志而不是最早的日志开始删除。同理，你总是会丢失一些日志文件，但你大概更不在乎那些较早的日志。
第三个 bug 和加密有关。有时服务器会无法对一个日志文件解码（我们一般不知道为什么——也许发生了位反转）。我们在后端没有正确地处理这个错误，而服务器会返回 500。客户端看到 500 之后会做合理的反应：它会认为服务器停机了。所以它会停止发送日志文件并且不再尝试发送其他的日志。
对于一个损坏的日志文件返回 500 显然不是正确的行为。你可以考虑返回 400，因为问题出在客户端的请求上。但客户端同样无法修复这个问题——如果日志文件现在无法解码，我们后也永远无法将它解码。客户端正确的做法是直接删除日志文件然后继续运行。实际上，这正是客户端在成功上传日志文件并从服务器收到 200 的响应时的默认行为。所以我们说，好——如果日志文件无法解码，就返回 200。
所有这些 bug 都很容易修复。前两个 bug 出在客户端上，所以我们在 alpha 版本修复了它们，但大部分的客户端还没有获得这些改动。我们在服务器代码中修复了第三个 bug 并部署了新版的服务器。
本文文字及图片出自 linux.cn
你的反应是：