How to find a bug?

印象中，有好几次被问到，我是怎么定位、处理bug的。

让我来理理看。

因为我的工作，从某种角度来看，就是“写bug，然后改bug”。

Bug是什么？#

我用“谷歌翻译”翻译bug，没想到除了虫子 之外，还会有其他的定义：

an insect of a large order distinguished by having mouthparts that are modified for piercing and sucking.（一类昆虫，它们的嘴可以扎孔、吮吸）

a miniature microphone, typically concealed in a room or telephone, used for surveillance.（一种用来暗中监视的小麦克风）

an error in a computer program or system.（计算机程序中的错误）

工作、生活中，谁跟我说：“这里有一个bug。”我是肯定不会想到虫子的，我会想到的是：“啊！！！怎么又来了一个bug啊？”或者是：“哎呀，好烦啊。我要把它卸了。”

Bug，深入我骨髓的认知：它不是虫子，它只是令人厌烦的——代码中的错误 。

为什么计算机程序中的错误会被称之为bug呢？

《程序员修炼之道》中有提到：

自从14世纪以来，bug（虫子、臭虫）一词就一直被用于描述“恐怖的东西”。COBOL的发明者，海军少将Grace Hopper博士据信观察到了第一只计算机bug——真的是一只虫子，一只在早期计算机系统的继电器里抓到的蛾子。在被要求解释机器为何未按期望运转时，有一位技术人员报告说，“有一只虫子在系统里”，并且负责地把它——翅膀及其他所有部分——粘在了日志簿里。

Bug分类#

我感觉敲代码，有时候和处理人生事物一样，都分一个轻重缓急。或者人生，就跟敲代码一样，要分轻重缓急。

让我用这轻重缓急给bug们起个好听的名字吧。

小可爱#

正式上线之前，所有被发现的bug都是小可爱。它们的出现，总是为我敲响警钟。#

小捣蛋#

当小可爱一直躲着，忽然在正式场合蹦出来，它就变成小捣蛋，让我不得不立马的去处理掉它。

大灰狼#

我的个乖乖，小可爱不止出现在了正式场合，还出现在很重要的正式场合。狠狠地咬我一口，好疼好疼。（有时候，还会有其他的bug生产者在这伤口撒盐）

蚊子#

哎哟。bug偶尔出现，我知道它存在，但我就是找不到它藏在哪里。我在它可能出现的地方都打上补丁，但它依然能够时不时的蹦出来。就像关灯之后的蚊子，一直在你耳边嗡嗡嗡；开灯找它，无影踪。

How to find a bug？#

为什么取名find（寻找）而不是fix（修复）呢？因为只有定位到bug之后，才能fix。而绝大部分情况都是定位很难，fix很简单。（有一段时间的心态是：我已经好几天都在找一个bug，我的月报可怎么写。）

小捣蛋与大灰狼#

绝大部分情况下，小捣蛋和大灰狼，会刷的一下就被定位。已经出现在正式场合的bug，代表玩家（作为游戏开发者，我们的用户就是可爱的玩家们啦）已经帮忙重现过许多次，按照对应的重现步骤，便可以搞定它们。

（大灰狼与小捣蛋的区别在于，小捣蛋只需要改掉便好。大灰狼却会留下后遗症，还需要许多额外的处理，比如补发、回收奖励，甚至回档。）

小可爱#

所以，为了减少小捣蛋与大灰狼的捣乱次数，找到、处理小可爱，便是工作的重点所在。用我目前的经历来说说看，我的应对：

小可爱们出生之前，尽量让代码结构清晰，便于阅读。（嗯，又是一门好大的学问。）弄清楚所调用的接口做了什么事情，怎么做的。

小可爱们出生之后，观察、记录它所产生的环境与留下的痕迹，找出重现步骤。

维护别人的代码，上下文看远一点；如果要迭代，请找到所有的引用处。（在这一点上面，我很有发言权，因为我的小捣蛋们，大部分，都来自于迭代、维护别人的系统。）

注重边界条件，小可爱们最喜欢出现在这些地方啦。

千万不要忽视只出现一次的小可爱，程序不会说谎。（曾经有一次，小可爱出现，我说“我这里不会啊”，最后就变成大捣蛋咯。）

最后，给自己多一点点时间，多看两遍自己写的代码，就像写公众号一样。想象一下，我的代码，不止自己看。

蚊子#

实在是找不到蚊子在哪里，所以我关上门窗，穿着衣服睡觉。我在蚊子出现的前后打印许多log，分析它所在的环境；蚊子把我咬伤了，我立马抹上膏药，让伤口看不出来痕迹。

当实在重现不了，试试看结对编程。

找一个人站在我的身后，耐心地、一行一行的为他解释，代码在做什么。或许，在某个瞬间，灵光一闪，就把蚊子找到啦。（没错，曾经有一个前后持续几个月的bug，我为它写了各种恢复措施、log分析，最终还是靠仔细读代码定位到它。）

愿我的世界，只有小可爱。

与我无关的bug#

碰到与我无关的bug，我是这么处理的：

如果这个bug很紧急，且bug制作者不在，我会帮着处理。

如果开发中，调用的接口出了问题，我会查询为什么，并先在本地改掉，让我的工作继续下去。再将bug报告给bug制作者。

但是，坦诚的说，碰到与我无关的bug时，也会看我是否忙碌、当时心情与bug生产者的往昔态度。（嗯，其实我并不想加上这一句“坦诚”。）

摘抄一段《程序员修炼之道》中的内容，书中提到：

发现了他人的bug之后，你可以花费时间和精力去指责让人厌恶的肇事者。在有些工作环境中，这是文化的一部分，并且可能是“疏通剂”。但是，在技术竞技场上，你应该专注于修正问题，而不是发出指责。

bug是你的过错还是别人的过错，并不是真的很有关系。它仍然是你的问题。 （原文链接）