让Bug来的更猛烈些吧

Bug有一种是技术bug，另外一种是业务bug。目前来看业务bug存在较多。

究其原因，还是对bug的态度问题：bug来了，恐惧。

       由于出问题，往往会对用户的使用造成影响，因此面对这样的问题总存在一些恐惧。担心对用户造成的影响有多大，担心自己的名誉是否受损，担心自己不能快速解决问题。其实越是这样就越容易让自己无法快速解决问题。

担心是无用的，问题来了就要勇敢面对。首要是要让自己冷静下来。

      那么什么是问题的关键点？

1、  充分理解问题的现象

     这点非常重要。解决问题就是在问自己哪里出了问题。如果问题都没有搞清楚，就开始着手解决，那是事倍功半，会造成多次的确认问题。充分理解问题，要从测试的现象、操作步骤来看和分析。不要想着自己去重现，问题一般不容易重现。就算测试水平不高，也要首先承认这是问题，然后再去分析。

2、  结合业务思考和定位问题

    在充分理解问题后，我们就要从业务的角度来理解问题，结合测试的操作步骤在大脑中构建数据的流程，进而定位到问题所在流程。

3、  借助业务流程，从代码结构定位问题

     流程定位到后我们就可以定位到代码的结构。因此代码的结构要出来好，一个流程点或功能最好能抽成一个方法。这样就可以直接去分析那一段代码。

4、  从具体代码处着手

     结构定位到，就要结合流程点的功能或者说业务来思考代码细节。因此一定要对自己的代码烂熟于心，定期review。经过以上的过程问题一般就找到了，如果还找不到就只能单步调试了。

5、  学会使用系统其它功能来创造数据

6、  单步调试

 

      综上，对自己负责的业务要烂熟于心，自己的代码一定要review。一方面是为了重构和优化，一方面是更加理解自己的代码（这点很重要，因为一段时间后自己的代码都会看不懂，哪怕有注释），同时也是更好的理解业务。由这一点扩展延伸到其它业务。review的过程一定是延伸的过程。我们要思考开发的周期，开发的流程，开发的逻辑结构，业务的细节，问题可能暴漏的地方。以上说起来容易做起来难。但是，只能 Just Do It And Now。