回想之前在大厂工作的6年里，基本有一半的时间在处理bug，久而久之形成了处理bug的一套实用的步骤。贯彻这套步骤，即使在解决难度很高的问题，也没有失去方向。

　　步骤1，重现问题

　　步骤2，寻找问题根源

　　步骤3，思考解决方案

　　重现问题

　　这个步骤里，主要是安装测试人员提交的bug里的描述，在自己的设备上重现问题。一个好的测试人员，不但会描述问题现象，还会描述测试步骤，和测试的前提条件。也有不负责任的测试人员，仅仅留下简单的问题现象的描述。无论是哪种情况，你都要找到重现问题的步骤，如果能在自己的设备上重现那就是最好结果。

　　1，要仔细看测试人员的描述，特别是重现步骤；以及她观察到了什么结果，认为是不符合预期的。有的时候可能是测试人员对需求的理解和开发人员不一致，而提出了bug。这个时候需要找产品经理来确认，究竟该是什么样。

　　2，问题的前提条件和重现步骤非常关键，只有这样你才能通过调试手段，不断缩小有问题代码的范围。

　　3，不要完全相信测试人员的描述。对于测试人员来说，系统就是个黑盒，她做出的一些主观判断可能并不精确，这就需要开发人员批判的看待bug单中的信息，分离出有价值的信息。

　　寻找问题根源

　　重现问题后，就可以通过调试手段来定位问题所在。不同的问题有不同的调试手段

　　1，打断点：这可能是最方便的调试手段了。

　　2，打日志

　　3，抓取网络包。。。

　　不够什么样的调试手段，一定是通过可以观察的现象，给提示信息。以前我做嵌入式的时候，会通过外接LED亮暗灯来提供信息。

　　思考解决方案

　　问题重现了，通过调试手段也寻找到了问题根源，下面就是考虑如何解决问题了。这里就考察你的老本行，开发的能力了。

　　1，因为你改的是老系统，一定要了解清楚之前的运作原理，才能设计方案。

　　2，对于设计方案来说，如果影响面特别大，必须告知相关测试。

　　3，修改完毕，比较自己设计测试用例，进行严谨的测试。

　　特别注意的一点就是，任何一个bug的解决，一定会经历以上3步。常见的误区就是没有这3步来走，失去了做事的条理性。

　　老大：昨天分配给你的bug解决的这么样？

　　小H：这个部分的代码很复杂。

　　老大：那么你知道这是个什么问题吗？

　　小H：Bug的描述里说了呀，但是这块的业务代码很复杂，我还在理解。

　　老大：那你定位到是那部分代码有问题吗？

　　小H：还没有，我还在理解这块业务的代码。

　　这种情况就是，以直觉来判断问题点，在尚未确定问题点的情况下，就开始展开针对性的准备工作。

　　另外要注意的一点就是，平和的心态对的bug。有人会觉得测试人员没事找茬，开bug就是对自己的人身攻击。承认自己的不完美，争取下次避免同样的问题，才是正确的态度。

　　为了让大家能按照步骤来思考，我定了条规矩：解决完一个bug后，必须在bug里按以下板式进行回复

　　问题原因：

　　解决方案：

　　总结（如何避免这样的问题）：

　　如何确定问题已经解决：

　　有没有类似问题：

　　影响页面：

　　这辈子做好两件事：1，编程；2，理财；