3、如果是差劲的用户体验或是未实现的功能

　　这个要与测试人员进行沟通，甚至是与管理层和设计者进行沟通，如何修改行为或如何实现行为，并且什么时候进行修改等，通常这个开发人员是没有决定权的。

　　4、尝试复现Bug

　　这个步骤也是很有必要的，因为即使你修复了Bug，也是需要复现Bug来进行验证以保证你真正的修复了。所以，如果无法复现Bug那么说不清是因为一直都没有复现还是被你修复了。

　　如前所述，如果你完全掌握了Bug所发生的条件，相关的操作步骤，那么复现Bug应该很容易，相关的操作步骤应该Bug描述都会有，但是Bug的相关条件（环境，配置，上下文和数据）这些东西可能要去挖掘才能知道，因为测试可能没有注意，也可能忘记添加到Bug描述中去，所以为什么第一步是弄清楚问题。

　　如果是真正的随机问题，那肯定是与线程时序相关的，对于这类问题，发生的原因通常是线程应用不当，产生的Bug也相当的隐蔽。对于这类问题的复现方法是，找到相关的代码逻辑和线程，进行人为的干预，以加大问题出现的机率，比如可以用Thread.sleep（）来阻塞线程，以让其以某种特定的时序来运行，以加大Bug复现的机率。

　　另外，如果难以完全复制Bug出现的条件，比如特定数据或特定的条件等，也可以通过修改代码来实现，比如某一逻辑只有当对象为空的时候才会进，但是99%的情况下它都不为空，且没有合数据让它为空，那么在代码中直接用空的对象，以复现Bug。

　　5、迭代：猜测问题并定位问题

　　这一步的目的是定位出问题究竟出现在哪一个源文件，哪一行或哪一逻辑中。当然，这一步要建立在Bug能复现的基础上。

　　定位问题也有很多方法，比如设断点调试，添加日志，一个很常用的方法是加上Thread.dumpStack（），以了解函数的逻辑调用关系。这个主要与软件的类型和开发环境有关，很多软件系统无法进行实时的调试。所以添加日志文件是通用的方式。

　　6、迭代：修复问题并进行验证

　　如果定位出问题了，可以进行修复，有些问题可能容易修复，有些问题可能比较复杂，这要视具体的软件和具体的问题而定。还有可能是，特别是那些没有需求规格的软件，会发现代码本来是这样子工作的，这时要与管理层和测试和设计者讨论这到底算不算Bug且要不要修复。当然悲剧的是发现引发这个Bug的原因是系统的架构设计不合理导致的，这个时候只能用其他方法而不是修改整体架构设计了，当然这个是前期设计造的孽，是否要改要看管理层了和时间预算允许不允许了。

　　这也是一个迭代过程，进行修复和验证，直到Bug被完美的修复。也是说Bug被修复，所做的修改小，且不会引发其他的Bug。

　　7、提交CodeReview并进行CodeReview

　　像开发一样，解Bug也是开发周期的一个部分，所以为了质量好还是要进行CodeReview。

　　Review的目的是让修改达到小，且不会引发其他问题。为什么让修改小，因为你改的越多，产生的影响也越多，如果没有足够的单元测试来验证，那么引发其他问题的可能性越大，所以对于修复Bug来讲，修改越少越好，改动的代码越少越好，修改的文件越少越好。（当然，理想的情况是不用修改代码也能把Bug给解了^_^）。

　　8、提交Patch和关闭Bug

　　这个是解Bug的后一步，但是也要小心，特别是对于公司所用的开发工具和版本管理工具不熟悉的人，一定要小心，因为即使你的Patch已达到优化，但是如果在Checkin代码时发生了问题，那是悲剧中的悲剧，如果引起了Build error那等着挨骂吧！

　　要注意的是把所有的改动都提交到版本控制中去，为了以防万一，在提交之后好再从版本中拉出来编译验证，一是看是否有Build error（通常是由于提交不全导致的），二是看是否有漏提交（结果是Bug没有解掉）。

　　总结

　　在《The Practice of Programming》（《程序设计实践》）有一句关于解Bug的话说的很好：Debugging involves backwards reasoning， like solving murder mysteries. Something impossible occurred， and the only solid information is that it really did occur.（解Bug/调试需要逆向推理，像侦破离奇的谋杀案。貌似不可能的事情发生了，而且确定的线索是它的确发生了）。仔细品味这句话，解决Bug的过程的确是这样。我们拿到是是Bug---一个结果，不断的尝试寻找线索，推敲去寻找它的原因，找到了原因了后再想办法修复它，我们是二十一世纪的福尔摩斯，我们是软件工业中的柯南。回头再看那些解决掉的神奇的Bug，与福尔摩斯破案后的感觉类似，也有相当的成感和自豪感。

　　后记：

　　关于解Bug有一本经典的书《The Science of Debugging》（《程序调试思想与实践》），这本书写的相当的实在，内容以Bug为主题，覆盖了解Bug所需要的所有话题，内容详实，完全是作者几十年作为Debugger的总结。在我看来这本应该与《代码大全》之类的平起平坐。感兴趣的朋友不妨读一读。