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的总结。在我看来这本应该与《代码大全》之类的平起平坐。感兴趣的朋友不妨读一读。
相关链接：
