高效解决bug的经验之谈

在大多数人的印象中，程序员是写代码的，从无到有写出一个好玩又酷炫的游戏。
然后事实却是程序员大部分时间都是在苦逼的改Bug，写代码仅仅占了程序员日常工作的一小部分。
中大型公司往往都有一整套完整的框架，新游戏的开发也只是在原有游戏基础上进行逻辑修改。而且中大型公司一般都有非常成熟的线上产品，维护好线上产品比不断开发新产品更有价值。所以很多时间都在优化产品，修改用户反馈的bug。
所以，如何快速解决Bug，是程序员必修的内功心法。当然，这也是经验积累所得。
能不能快速地定位 Bug，解决 Bug，也是检验程序员新手与老手的一种方式。

程序员老手是如何定位并解决Bug呢？
其实都是有套路的，且听我慢慢道来。

经验预判
测试人员反馈过来一个Bug，首先可以根据经验判断下，是否真的是程序出了问题。
因为他们说的bug，有些时候根本不是Bug。
根据反馈，我们需要先判断是否确实是Bug，可以从下面几点进行分析：
1.是否软件版本号不一致？你可能已经修复了这个Bug，并发布了一个新版本，但是测试人员可能没有及时更新，用的还是老版本
2.是否测试环境没有设置正确？比如有些公司是区分内网版本和外网版本的，确定版本是否正确。
3.是否测试人员没有理解好游戏规则，而误认为是Bug。
4.是否测试工具有问题？不一定是你写的软件有问题，有时候还有可能是测试工具的问题。
5.是否是一个已知而又暂时不好解决的bug？比如这个 Bug 跟一个已知的硬件 Bug 相关，而这个硬件 Bug 暂时又解决不了。

猜测解决方案
在确认完Bug之后可能会有大致猜测，可能是哪部分代码出现了问题。如何自己没有想法，也可以向有经验的同事请教。
可以试着修改代码，修改后自己再测试下，如何已经解决，便可以提给测试人员进行测试。
这个步骤就要依赖你对代码以及产品的熟悉程度了。可以避免本地复现Bug的时间和精力消耗，因为有时候，复现Bug其实也是一件繁琐的事。

复现Bug
凭借经验，没办法一眼看出问题所在，那就只能先复现Bug再进一步分析。
复现Bug有时候也很费时间精力，可能软件、硬件、测试工具、测试案例、以及各种测试环境配置都要匹配。
所以前面说的能通过经验大致确定问题所在，是解决Bug最高效的方法了。
Bug一般有必现和偶现之分，必现的Bug就是已经确定产生该Bug的确切操作，这种的复现起来简单，改起来也相对容易。
偶现的Bug就有些令人头疼，你不知道产生这个Bug的确切操作，同样的测试环境就是很难重现，确定不了产生Bug的操作，就很难定位出错的代码。然后就只能一遍又一遍的跑程序，等待Bug重现，确定产生Bug的操作。像是等待彩票开奖一样，这心情，只有经历过的人才懂。
说了这么多，只是想说明，复现 Bug， 有的时候，是真的很繁琐。

开始调试
如果复现了Bug，并确定了产生Bug的操作，那么接下来就进入正经调试阶段。
1.查看日志信息，大型软件项目都会在程序运行过程中保存相应的Log。可以先查看下Log，是否有错误信息，这是最直观的方法。
2.用调试工具进行代码跟踪调试，跟踪下代码逻辑，看有没有发生逻辑错误，看下各个变量的值是否符合预期，有没有数值错误，数组是否越界，代码是否执行到了异常处理区等。
3.在需要的地方添加打印代码。有些时候，调试跟踪不是很方便，或者在多线程情况下怕影响时序，可以将数值打印处理，看看是否符合预期，有没有明显错误的地方。

修改代码
经过反复调试，你一定有了大致猜测，接下来修改你怀疑的代码段。
这个过程不是一蹴而就的，需要不断的修改和验证。
1.如何你已经确定了产生Bug的确切原因，那你就可以直接改正。
2.如果还不能确定，可以尝试下代码分段注释法，先注释一半代码，看Bug是否消失，然后再注释一半，反复操作，逐步缩小产生Bug的代码范围。

解决问题
在确定了Bug原因之后，解决Bug反倒不是很困难。当然也存在例外，有些程序确定了Bug原因，修改起来却异常麻烦，无从下手。
先自己动手解决，如果解决不了可以请教有经验的同事。
修改完代码之后，先自己多测试几遍，确定没问题再提交给测试同事进行测试。
测试通过之后，先Compare核对下代码，然后就愉快的Commit吧。

发布到正式环境一段时间后，没有再收到客户对于这个Bug的反馈，那这个Bug的生命周期就至此结束了