我 不在乎你怎么说。如果你在开发代码，即使是在一个人的团队，没有一个组织的列出代码里所有已知bug的数据库，你将会产生出低质量代码。许多程序员都认为 他们能把众多的bud存在脑子里。真是胡说八道。我根本就不能再同一时间记住两个或三个bug，第二天早上，或者在写代码的高峰时期，就记不起它们了。你 绝对要正式地跟踪bug。
但数据库可以是复杂或简单的。一个最小限度的bug数据库必须包含以下对每个bug的数据：
再次出现这个bug的完整步骤
预期的行为
观察到的行为
它是被设计来干嘛的
它是否已被修复
如果bug跟踪软件的复杂性是让你不想跟踪你的bug的唯一理由，只用上面包含简单的5个元素的表格用在这些至关重要的领域，开始使用它吧。
你在写新代码前会修复bug么？第 一个版本的Windows系统上的微软Word被认为是一个“死亡行军”项目。不知道这项目要什么时候才能完成，它不断的延期。整个项目组在荒谬的时间里 工作着，项目再次、再次、再次延期，这时候的压力的令人难以置信的。当讨厌的事情最终出货，几年以后，微软把这整个团队都送到坎昆去度假了，他们可以静下 来做些严重的自我反省了。
他 们意识到，项目经理一直在坚持按照“日程安排”部署工作，而程序员们只是头脑简单的赶紧完成敲代码的过程，又因为修复bug阶段并没有成为正式日程安排的 一部分，这导致他们写出了及其恶劣的代码。没有能试图保持住bug不发作的倒计时。恰恰相反，据说一个程序员写了计算文本行高的代码，仅仅写了 “renturn 12;”然后就开始等待关于他的功能总是正确的bug报道。日程安排仅仅是即将变为bug的功能的检查清单。事后，这个被称为“无穷大缺陷的方法”。
为 了解决这个问题，微软普遍地采取了一种叫做“零缺陷方法”的东西。公司的许多程序员都咯咯地笑，因为它听起来是一种好像通过行政法令就能够减少bug数量 的管理思想。其实，“零缺陷”意味着在任意给定的时间内，优先级最高的是消除bug，然后才是编写新代码。让我来讲讲为什么。
一般情况下，你等待修复bug的时间越长，这个bug就需要付出的代价就越大（在实践和金钱上）。
比如，当你犯了一个编译器能捕捉的拼写或语法错误时，修复它的代价微不足道。当你第一时间看到你尝试运行的代码里有bug的时候，你能够很快的把它解决掉，因为所以的代码在你脑子里印象还很清楚。
如果你在几天前的代码里发现了bug，你会花费一段时间来找到它，但当你重读先前写下的代码后，你就会记起一切然后就能在一个合理的时间内修复这个bug。
但 如果你在几个月前的代码里发现了bug，你很可能把关于这段代码的大部分东西都忘了，要修复它就很难了。这个时候你可能正在修复别人代码里的bug，他们 可能会在阿鲁巴岛度假，这种情况下，修复bug就像科学一样：你不得不放缓步调、有条不紊、细致地开始工作，并且你还不能确定需要多长时间才能找到问题的 治疗方法。
如果你在已经售出的代码中发现了bug，你会招致令人难以置信的代价修复它。
这 是要立刻修复bug的一个原因：因为这样花费更少的时间。这关系到写新代码之前而不是修复bug之前还要等多长时间。比如，如果我要你预测写一个给列表排 序的代买要多长时间，你可以给我一个很好的估计值。但如果我要你预测修复一个安装Explorer 5.5版本后代码就不能工作的bug需要多长时间，你猜都猜不出来，因为根本不知道到底什么导致了这个bug。它可能需要3天时间才能跟踪到，或者仅仅3 分钟就足够了。
这句话的意思是，如果你有一个很多bug有待修复的日程安排，这个日程是不靠谱的。但如果你修复了所有已知的bug，并且所有剩下的都是新代码，这样你的日程安排才会更加惊人的精确。
关于把bug控制到零还有另一件重要的事，那就是你可以对竞争响应更快。一些程序员认为这点能让产品在任何时候为发售准备好。如果你的竞争对手从你的客户那里引入了一个杀手级的新功能，你就能在发售之前只实现这个功能，而不必去修复大量累计下来的bug。
你有最新的日程安排么？