解决bug的一些总结

        今天我们就来说说，程序员的日常工作之一解bug，解bug时间与正常编码时间几乎都快符合二八法则了，当然是bug占八了。
        接下来笔者会围绕bug产生的原因，各种类型的bug修复方案，以及如何必免大部分bug的产生，来一探bug的真面目，希望能对您有所帮助。
        首先我们来看一下，都有哪些原因会产生bug呢？以笔者经验来看，可能有如下几条：
         **1.业务需求没搞清楚，这种是典型的逻辑bug，不符合基本的业务逻辑。
         2.没考虑边界条件，或完全没处理边界条件。
         3.马虎大意，如等号写成了赋值，少个逗号，变量引用错误等等。
         4.第三方库的bug。
         5.编码不一致引起的乱码。
         6.ui没有自适应，引起文字超出或布局错乱
        7.改了他人遗留代码。
        8.自己觉得可能是个bug。
        9.如果是手机应用还有屏幕适配问题等等**
      简单介绍完bug产生的原因，接下来说一说不同情况下bug的修复方法：
       断点调试法：这种是比较常见的修复方法，在代码适当的位置加上断点，按步看执行逻辑，找出原因。一般适用于重现步骤明确，必然出现的bug。
       版本比对法：一般是切换到最后一次稳定版本，和刚产生bug的那个版本做比对，看前后代码有什么不同之处。这种适用于在稳定版本上改出来的bug，时间紧迫，调试较慢，或重现步骤不明确等情况。    
        打印输出法：和断点类似，只不过是断点变成了输出打印，可以输出到控制台，控制台不方便看的也可以输出到文件或屏幕。这种省去了启动调试模式的步骤，适用情况和断点调试类似。
        删代码法：删去部分代码运行观察，一般会找到关键的一行，然后对该行分析，查找原因。此法多见于调试或看代码逻辑没发现问题时。
        假设法：根据bug的表象，假设bug产生的条件，并通过编写假设代码，人为重现出来，并尽一步分析原因。这种适用于偶现，重现步骤不明确，但又比较严重而不能忽略的bug。
      直接读代码：就是直接逐行读相关代码，仔细分析问题所在，虽然这个方法效率比较低，但有时面对一个不容易重现的bug，还是很有效的。
       忽略法：顾名思义就是直接无视，适用于非常不容易重现，不影响系统正常运行的bug，但选择忽略之前一定要仔细分析定位，反复确认，不然忽略可能会埋下隐患。
         更改需求法：有些bug可能是某些条件或需求没考虑，后期测试覆盖了此种情况，这种情况下，可以做些沟通看是否可以更改下需求，以消除bug。
      说了原因和方案后，笔者觉的，其实大部分bug是可以避免的，因为大部分bug是马虎和沟通不善引起的，关于这个问题笔者会专门写篇关于bug产生原因和避免的文章。敬请关注！！