如何在恰当的时间处理恰当的bug一 (1)

通常关于处理bug的准则是：修复bug使得结果尽可能的正确。这个道理似乎是显而易见的，但是确实是这样吗？不，不是这样的。我敢打赌在你使用过的那些存在很多bug，性能极不可靠的软件中，大多数并不是因为开发者没有时间改善它们，而是因为他们只是简单地修复了错误的bug。想要修复正确的bug和知道如何修复是两件不同的事情。
　　
　　要做出准确的处理bug的决定，需要回答两个问题：首先，要明白如何才能做出一个好的修复bug的决定；其次，制定一个步骤，要求这个步骤能够在项目压力大的情况下也能很容易得到执行，并且执行这个步骤。
　　
　　明智的领导者和有经验的团队知道，每当项目快结束，或者出现重大转机，或者项目重复循环中，他们将非常容易疲惫不堪。在这个过程中，他们可能睡得更少，更努力工作，并且消耗无数的咖啡。聪明的领导者如果提前考虑的话，就会订制简单的规则，在适当的位置预先放置急救装置。那么当时间紧迫的时候，就能很容易的定制快速简单的bug修复方案。
　　
　　这篇论文分为两个部分，简单描述了上面说的定制的规则和那些预先放置的急救装置。更重要的是，我将提供让你制定自己的规则所需要的核心思想。我们将这个建议分为四个等级，从简单急救(第一等级)到高性能计划(第四等级)。但是首先，要避免那些看上去有趣但是完全没有必要的方法。
　　
　　十种最糟糕的处理方法：
　　
　　10.只修复那些让你的CEO苦恼的bug。
　　
　　9.修复每一个bug。(总也不交货)
　　
　　8.不修复任何bug。
　　
　　7.只修复那些让CEO的配偶，女儿或其宠物感觉烦恼的bug。
　　
　　6.需要将每个决定让团队中最令人讨厌，最愚蠢的人批准(这点和第十点比较起来有点多余)。
　　
　　5.没有规律地开始修复一个bug，当你做到一半的时候，又转向另一个bug。一直重复循环如此。
　　
　　4.看待bug就如同一个烫红薯。不修复它，只是将你的bug委托给其他人。
　　
　　3.给bug编号，按照字母顺序由A到Z，跳过元音字母。(如果你重新将它们适当的编号，这一条和第八条是相同的)
　　
　　2.成立一个复杂的议会机构，并从三分之二的主要成员中选举出代表，来起草一个规章制度作为小组委员会的正式文件，使得将来与管理人员谈论项目中的缺点时，可以有缓冲的余地。
　　
　　1.花费所有的时间来讨论当前的操作是否在上面这些列表里。
　　
　　真心的希望，你从来没有在实际的工作中遇到这些行为。现在你已经得到了警告，所以你们在将来能够避开它们。如果你的上司建议你做上面所说的任何一条，那么你可以马上站起来，安静地转身，然后跑得能有多快就跑多快。
　　
　　第一等级：急救
　　
　　在最好的网站和软件开发公司，bug管理就如同医学上的优先治疗选择(译者注：将受伤人员按轻重缓急或立即治疗的可能性进行分类的过程)。一些人根据一些规则将收到的bug归为三到四个基本的种类里。(这叫做：治疗等级选择，bug竞争，或者叫做缺陷管理。)就像那些你可能大量拥有的事物，比如CD碟片、书籍、债务、或者女朋友，组织管理bug的唯一方式就是将它们归结成更高一级的组群。这将能使你更容易的了解到你得到的到底是什么，使你更加方便的同其他人讨论它，并且找到合适的处理它的专家。一个普遍的规则是，把事物归为三到四个组群比成千上万个独立的个体更容易管理和工作。
　　
　　当bug数量增加到严重影响工作的时候，最好的急救是停下你手中的所有工作，拿出一个下午来做修复归类。(如果你记不起来上一次做修复归类工作是什么时候，那么你现在应该停止阅读这篇文章，马上去做这件事情。)