Bug，一种传说中的昆虫类动物。形状多变，往往根据生存环境随意变化其外形特征。常常和一类叫做 “程序猿” 的灵长类动物共存。而猿在工作之余，往往以抓杀自己的 bug 作为消遣。当某些 bug 演变成具有较大破坏性的时候，集体捕杀，或是替别的猿抓杀其 bug 的情况，在猿族内也常有发生。

Bug 的繁殖环境

Bug 的繁殖速度，总的来说，和三个条件有密切关系。

一是猿自身的清洁卫生的保持情况；

二是他们的工作强度有密切的关系；

三是工作环境中各种防虫措施的有效程度。

一个项目的推进，通常有四种情况：

负责的程序员，紧张的进度：这种情况，往往也是一个快速试错、快速迭代的开发流程。在开发的过程中，可能会出现一些 bug。但是因为程序员还是很负责任，所以在项目收尾后，会有自发的 bug 清理。因此，虽然过程中很多代码不够理想，但是开发速度极快，最后状态也比较优质。缺点是中间某些阶段代码质量（即使是没有上线的）可能被质疑。

不负责的程序员，紧张的进度：和上面类似，但是最后系统中会埋下很多没有妥善处理的坑和 bug 蛹。给后面维护的程序员带来很多不便和负担。

负责的程序员，不那么紧张的进度：这种时候自然可以不紧不慢，三思而后行。Bug 生的少，但是开发的速度也会稍有延缓。

不负责任的程序员，进度是不是紧张，他们也不管：做得越少，错的越少。这种情况下，bug free 都是有可能的，反正项目能不能按期，不关他的事。

所以呢，如果上层的管理者真的了解情况，或是对你有信任，那么只要你负责，交付的是好的实现，那么上面的第一种和第三种都是比较理想的结果。如果又有很紧张的进度，那几乎所有有开发经验的人都知道，快速迭代是最有效的开发模式。尤其多个工程师同时改相关的代码，在开发的过程中，不可避免因为相关、依赖等原因，有些中间状态的代码会有瑕疵。

如果上层的态度不明确，或者有盯着你要给你小鞋穿的人，那么做不到第三种，就不妨做第四种。而最吃力不讨好的，就是第一种。

如果根本没有人在乎代码质量，只在乎进度，那么就是第二种了，也是最糟糕的一种情况。

Bug 的遏制

如果系统里已经有很多 bug，而且有些因为寄生太久，已经搞不清是从哪里冒出来的了，又要怎么尽量达到一个 bug free 的环境呢？

当团队很小的时候，很多靠自发自觉的潜规则都可以很好的运转，大家都比较自觉的维护代码的质量，bug 抓一个修一个。而当团队大到一定程度的时候，这种自发自觉便逐渐失效。靠一些人的努力，bug 似乎根本修不完。

举个例子。在一个组里，往往会出现这样一种情况：小 J 经常主动帮助修理一些 bug，所以她了解的业务逻辑越来越多。一方面，她的成长很快，但这种快一定会达到一个瓶颈。另一方面，出现 bug，很容易别人就找她，她修 bug 也会越来越多。

而一些平时因为种种情况（懒、滑、太忙、不太懂……）从来对 bug 连推带拖的人，找他的人也会越来越少。对这种人而言，系统了解的少，但是也省出一些时间。

所以，从某种意义上来说，这种不公平很容易产生。而且产生的特别自然，并进入一个良性还是恶性的循环。而最终，小 J 也会对太多的 bug，或是因为自己太忙，而无能为力。

另一个现象，就是大部分所有权明确的 bug 很容易得到处理，而一些三不管地带的 bug，往往可以被一再忽视，成为千年老 bug。比如，一个项目遗留的 bug，但是整个项目组都已经拆了；比如，一个前员工留下的 bug，但是这个人已经离开很久了；比如，很难界定这个 bug 属于哪个组，或者需要动的代码涉及到外组等等……

而这样的 bug，如果没有从上层发起的重视和方案，或是几个真正把公司的事看成自己的事的能人，往往不论影响多少用户，也很难被重视。

和一个高层的管理人员讨论过相关的话题。高管说：可以通过一定的奖励机制来鼓励修 bug。但我不禁提出几个质疑：

   1  如果奖励修理 bug，那么必然 bug 多的组更有可能修理更多的 bug。这会不会从某个意义上，又伤害到代码质量？

    2 有一些人修理的是自己的 bug，这种该不该奖？

   3  会不会有人过于耽于找 bug，修 bug，而影响到正常的开发工作？

高管说了这样一段话。

很多 bug 的道路，就好像在没有告诉公路上行驶的很多车辆。不论怎样，你都快不了。当有这样一个机制来鼓励清理 bug 时，就好像是修了一条高速公路。这虽然不能保证所有的时候所有的车都可以畅通无阻，也不可避免有的人开始飙车，引起别的问题。但至少，在这条路上，除非出了事故，否则你就有了最低限速，确保大部分时候，还是比没有这条路时，交通要好的多。

想来似乎也很有道理。