学会定位bug真的很重要

1、定位bug的数量、种类、级别越多， 真的真的真的（重要的事三遍）能快速拉升自身编码水平、对很多原理的理解和对编程的认知。

2、能提高开发效率很多很多， 避免长时间都在解决bug的路上。

3、对app也是相当友好，至少对自己的app稳定性信心大增。

“打怪升级法则”

本人是个游戏迷，对于程序员的成长历程，觉得就像是在玩游戏一样。 只有不断的增加经验，获得新的装备，才能提高自身战斗力， 才能被一些“组织”收纳。游戏中有很多途径可以去增加经验， 同样对于程序员的成长也会有很多方式去提高自己的编程能力，这里闲谈一下定位bug的方式去提升。

开发过程中，会出现各种bug，产生原因不一。 如果对每种类型bug都能透析产生的原因和如何避免。 就会对各个开发知识点都会有更深刻的见解。所以《打怪升级法则》最重要的一就是积累各种bug， 只有见多识广才能应对自如， 建立自己的bug库很重要， 这里会说两点如何建立自己的bug库。

法则一 ： 刷自己的副本

根据自己开发过程中所产生的bug， 包括代码类型bug，策略类型bug，业务类型bug。 每个bug都要寻根问祖找到根源， 如果只在半途解决或者屏蔽bug，那么就领会不了这个bug的精髓（至少前期积累bug库的时候都要寻根问祖，如果后面经验丰富能对bug很熟悉，或者能很优雅的屏蔽后可以忽略）

· 代码类型bug的产生一般来源于自己的编码不够规范和严谨， 透析此类bug可以提高自己的代码质量和编程能力。

· 策略类型bug 一般来源于自身的代码设计有缺陷， 透析此类bug有助提高我们的代码局部或者全局构造能力， 可以为后续的封装、组件化、架构设计思维有很大的帮助。

· 业务类型的bug很明显来源于自己对业务流程、需求逻辑的理解或业务代码设计不够严谨产生的bug， 此类bug也是相当重要，如果前面两点说的是对于自身编程能力， 那么这点就是切切实实跟业务开发有关，也是最常见的bug。 自身编程能力作为基石，只有自己的代码质量提高了才能编写出优雅高效率的代码。 但如果自己对业务的理解很马虎很随意， 即使编程能力再强， 也只能是一个很普通甚至差劲的程序员。程序员的本职是对一个产品赋予头、手、脚、躯干等等（功能），如果不能制造出健全稳定的功能，那么最终的产品可能就会是一个残废 。 透析此类bug， 对自己的业务能力， 功能分析，方案制定有很大的帮助； 还能获得部门的认可。 业务能力，也是公司晋升的重要衡量指标。

总之，一个bug就犹如一个副本，自己的副本都不刷掉，那升级就会很慢； 如果对于自己的副本只刷掉门口几个小兵，中途就离开，其实也跟没刷一样。 只有在干掉最终boss， 才会有成就感，才能拿到本副的装备， 才能以更高的战斗力去刷其他副本。 装备越来越多，越来越好，那升级就是分分钟的事情。

法则二：跟同事组队刷副本

上面论述的是针对于自己在开发过程中遇见的bug， 这类bug实际上是很局限的， 如果你处于一个版本迭代流水线式的开发环境， 每天造轮子、造螺丝， 在开发过程中遇见的bug会更有限。除了刷掉自己的副本外， 还要学会如何吃掉别人的经验。

当身边的同事有问题时，这时候一定要伸出援助之手（xx副本求带）。 因为除非是实习生，同等水平左右的同事发出的“求救信号” ， 大部分是自己偶尔遇见过但却忘了，或者自己根本不熟悉的bug。 这是一个增加自己bug库的大好机会，即使是自己熟悉的bug，也别放过， 也许你觉得会耽误自己的时间， 但很多时候会重新刷新你对上一次bug的认识（也许会捡到+1的新装备哦），还能促进同事之间的关系。 如果是全新的bug， 之前自己并没有这方面的bug经验， 那么升级的时候就到了， 因为往往这类副本难度偏大，但boss经验多，装备豪华， 如果你能和同事组队干掉，必然会经验大涨。但对于那些难度太大，耗时很长的，也并没有要求你就此一直卡在这副本， 你只有50级的装备却想干掉100级的boss，毕竟那是你同事的bug，他会寻找资料或者更高级别的大神来解决， 此时只需等待同事的心得就好了。 当然如果你有多余的时间可以慢慢研究，收获更多。

法则三：吃别人经验

除了自己的bug和同事的bug外， 还有很多bug是我们不熟悉的。 当自己的bug库有了一定的积累， 定位bug有了一定的经验和心得后，可以去逛逛论坛、交流群、博客等，见识见识别人的疑难杂症和解决方案， 这会有助于提高自己bug定位能力和解决能力。

如果能有上述或类似的一些习惯，我相信用不了多久， 你们代码中的bug会越来越少，定位bug也将会轻车熟路， 个人能力会得到很大的提升。

“开局一堆bug，装备全靠刷。 我是渣渣辉，皇城pk，等你来战”

定位bug

上面用了大量的篇幅介绍了定位bug的重要性以及如何建立一个自己的bug库，（这里说明一下， bug库并不是用笔记做成的仓库， 而是对各种bug理解认知之后的集合，如果担心被遗忘做笔记也是很好的。） 并没有介绍如何去定位一个bug的根源，与分析bug产生的原因。我相信每一个程序员都有自己的一套定位bug的方式。 这里简单介绍一下以常用思维去分析定位一个bug，当然大神很多，可用以自动化的方式去定位项目中的bug，如使用工具、脚本等方式。

猜测

当发现一个bug时，首先要做的就是分析猜测这个bug会产生的原因。

· 一般业务类型的bug最容易猜测，如：文案错误，信息空缺，集合元素缺失，等数据不对的情况。此类bug基本上都是数据在最终使用的时候，并不是自己想要的数据。如果能对自己代码比较熟悉，那么就能很快的猜测出数据在获取 - 解析 - 传输 - 转换 - 使用 的哪个环节出了问题。 如果无法猜测数据在哪个环节出了问题， 排查起来也相对简单，数据的传输在代码中还是很清晰可见的。 只要顺藤摸瓜很快就能寻找到出问题的地方。 PS： “数据驱动编程”， 从数据源上规划好数据结构，不仅可以避免掉很多不必要的bug，还能提高开发效率。

· 其次是策略类型bug，功能映射到的代码设计有缺陷，猜测此类bug难度会大一些。 因为很多时候咋一看以为是业务类型的bug。 猜测此类bug产生的原因，一是需要全局回想下自己的整体设计思路，确认是否有隐患的地方， 二是根据bug发生的场景、时机，推算猜测出可能存在的错误设计思路。 如果发生较大的策略类型bug， 其实是很不好的，这很可能意味着自己之前的大部分设计思路需要调整，相应的很多代码也需要调整。 虽然要调整的地方很多， 但另一方面， 也说明了你正在改变， 你重新设定了一套设计思路，你在追求最优化，而不是去建立补丁。 PS： 拿到需求后去思考最优化方案是很有必要的。

· 再次是代码类型的bug， 由于自身编码规范不足，埋下一些坑，出现的一些奇葩bug。 要想猜测出此类bug产生的原因也是最难的， 它很可能跟数据关系不大，跟策略设计的影响也不大。 想要猜测出此类bug发生的原因， 需要结合更多的信息， 如 log、场景、时机、数据等， 加上经验和感觉去推理猜测出bug产生的原因。 PS： 提高自己的基础和注意平时的编码习惯，应该是每个猿需要做的事情。

不管是什么类型的bug，当bug发生的时候，很多时候我们并不会知道这个bug是什么问题造成的，所以在猜测的时候，需要对业务类型、策略类型、代码类型的bug结合进行推理猜测。

定位

当我们大概猜测出一个或者多个可能产生这个bug的原因后， 我们需要去定位具体产生bug的代码。由于猜测环节我们已经把范围缩小到了某一区域。 如何在这个范围定位到具体的问题代码？ 这里可以提供几种思路可以参考下， 一是直接浏览一下这块代码，排查有隐患的地方。 二是模拟数据、场景、时间，确定有问题的代码。 三是折半注释法，通过折半注释能快速的定位到具体代码。 折半注释法在很多疑难杂症bug中更能见到奇效，通过注释掉一部分代码，让产生bug所处的局部功能运行正常， 再放开被注释掉的一半代码，使运行正常，直至找到最终打开注释就会有问题的那块代码。 或者反注释，一个个打开注释判断是否正常，最后留下的将会是有问题的代码， 此类方法只能做辅助。

验证

验证就很简单了，定位到具体问题代码后，我们需要验证各种数据、场景、时机来完全确定是这里代码产生的问题。

猜测 - 定位

有些时候从猜想 - 定位 - 验证， 最后可能会发现并不是这里的产生的问题， 这时候需要重新去猜想和定位其他case。

其他方式

定位bug的方式有很多，也根据具体情况而定，只要积累的够多， 不管用什么方式去定位都将会很快， 很多时候也许一个感觉就对了。 不管是建立bug库，还是学会如何定位bug， 都是一个持续的积累过程，也是一种不可言传的编程思维，这里只是简单的描述大家都懂的道理，只有自己去体会实践才能收获。

转载：http://www.51testing.com/html/71/n-3725771.html