摘要：我很喜欢看各个产品的Bug追踪系统，比如jQuery的Bug Tracker，因为在Bug系统中总能发现一些非常细节的问题，补充自己的知识，慢慢地自己的代码的兼容性会有很大的提高。

　　我很喜欢看各个产品的Bug追踪系统，比如jQuery的Bug Tracker，因为在Bug系统中总能发现一些非常细节的问题，补充自己的知识，慢慢地自己的代码的兼容性会有很大的提高。

　　但是，在各个Bug系统之中，包括现在公司使用的Trace系统，无一例外地存在一些让我不满意之处，其中最大的原因就是很多Bug系统仅仅是作为Bug的记录系统存在，而没有试图去让一个Bug成为一个知识的积累，让整个Bug系统变成一个丰富充实的知识库。这样的Bug系统，永远都只是提供一个简单的业务流程，不会变成干完人员、产品、甚至是整个团队的进步的天梯。

　　在我看来，一个Bug系统应该更加全面，管理Bug的生命周期的同时，也用于管理一个产品、团队的知识，更可以与周边系统合作，形成一个真正的集成式管理平台。

　　Bug的分类

　　现在的Bug系统，对Bug系统的分类通常有这么几种：

　　● 根据性质：Bug、Feature、Enhancement等。

　　● 根据危险程度：Trival、Minor、Normal、Major、Critical等。

　　● 根据模块、系统、可重现性等与项目紧密相关的分类。

　　但是这些Bug系统往往忽略了一个很重要的分类方式，那就是“按Bug影响面分类”，在这种分类模式下，一个Bug可以根据其影响的范围来进行区分：

　　项目型Bug

　　与当前项目的业务流程、逻辑等有紧密关系的Bug，此类Bug只可能在当前项目中出现，离开了项目的大环境就没有任何存在的意义。

　　针对此类的Bug，只需要在当前的环境下修复即可，不需要考虑太多的问题。

　　复发型Bug

　　此类Bug通常也与项目有紧密的关系，但是此类Bug在项目的整个演化过程中一而再再而三的出现，也许每一次出现的原因有些许差异，但表现上极其相似。比如某系统每天下午17：00左右会出现无法提供服务的情况，在第一轮修复的情况下，几周后继续出现此类情况。

　　在这样的前提下，该问题就应该被评定为复发型Bug。对于复发型Bug，项目管理层及开发人员都应该给予绝对的重视，投入足够的人力和时间来对问题进行彻底的跟踪和追查，以期从根本上进行解决。

　　同时，在问题被定位并修复后，可以进行一次case study，以杜绝此类问题的再次发生。

　　通用型Bug

　　此类Bug是我认为当前的Bug系统最没有关注到的一个问题，而且相比前面两类Bug往往可以在项目层面通过制度和流程来进行规范，通用型Bug是一个最需要自动化处理的问题。这往往涉及到不同团队之间的合作，也是Bug平台成为一个知识库的最为基础的条件。

　　顾名思义，通用型Bug即与项目本身的业务没有任何关系的，仅仅是技术上存在的问题。比如我最近发现的一个Bug，其可以用以下的代码来表现：

　　这个Bug很明显，是不属于任何项目的，即所有项目在特定的情况下都可能使用类似的代码，产生相同的Bug。