编程回忆之运维回忆（bug记录收集和处理）

        有人在疑问，做实施和维护不是一件挺简单的事儿，也不用像程序员如此苦逼的加班敲代码什么的。嗯嗯，这个说法也是没错的，一个成熟的实施维护人员，懂得如何一劳永逸的解决问题，不用天天苦逼的跑现场，累得像狗一样。

        那如何做一个成熟的实施维护人员，我说一个最简单的方法，记录问题。这件事情，说起来貌似是一件挺简单的事儿，但是一件事情只要经过足够的细化，任何简单的事情都会变得不再简单。记录问题，选用什么样的材质去记录问题，记录方式是要粗记还是细记，记录问题是否需要标注重点，重点分级（例如需要汇报,不需要汇报），哪些问题需要重复整理。

        这些事儿，我们一件一件来说，记录材质，除非一些特殊情况，我强烈建议就用笔记本和笔，如需嫌数据脏乱，再使用别的工具进行整理。

笔记本选用带有硬纸板的笔记本，好拿好记，笔用较粗的黑色水笔，带两支，防止一只坏了，还有另外一只。记录的时候，字体草一点，没关系，但至少保证自己看得懂。如果自己都看不懂的话，整理记录的时候，你会极其的痛苦。

        一个问题要粗记还是细记很大程度上取决于这个问题是否出现过，如果已经出现过，或者出现过类似的问题，只要需要粗记即可，反之就需要细记。为什么这么说，如果一个问题已经出现过，事后查看记录，根据粗记的记录，你也能回忆起来这个问题到底是咋回事。反之一个问题如果是新出现的，则需要细记，以备事后方便查询。

      怎么去区分一个问题的重要性，简单的这么说，一个项目里面，如果出现了某个问题，这个项目流程就会受到干扰，或者出现了某个问题，这个项目的报表就会数据错误，这个问题就可以归类为重要的问题。那问题的重要性，怎么去分级。这个没有一个确切的标准，主要看这个问题影响的深度和广度。什么叫深度，比如说出现了某个问题。项目某块功能直接不能使用了，这个叫深度。什么广度，比如出现了这个问题在这个项目的多个地方同时出现，或者这个问题影响了这个项目很大部分功能。根据情况，一般优先解决深度问题，广度问题可以先放着，但不能拖太久，一拖太久，广度问题所产生的工作量是你不想面对的。

        

    特别是在项目刚上线的时候，会收到一大堆的问题，这些问题，哪些需要整理，哪些需要就此搁置。为什么要整理，说白了，就是为了方便以后维护的时候查询问题。所以收到的问题，和以前的问题库就行一下比对，如果出现过，就不用仔细整理，只要在原本的问题库里面做上标注，比如该问题出现次数+1，该问题出现了什么样的变种。如果是新问题就需要详细整理，将其录入问题库里面。