本文分享了一次解决复杂BUG的经历，总结出了两个重要的教训：一是要充分利用开发工具的重构功能，二是遇到系统运行错误时应该善用调用堆栈来定位问题。
时间再紧，还是记一下吧！记下小成功与小失败，继续往前。
故事
近一天多时间，（其实在前几天中就隐约出现这个BUG，只是当时没有系统地或者频繁地调试运行故没有发现）被一个BUG折磨得够呛！
现在归纳来看，根本原因还是自己对于开发工具不熟练。今天再次出现这个BUG，因为代码太长了，没有办法，只得大致根据代码执行流程及自己的经验分析诊断。
今天休息间（临时被BUG折磨，只得休息一下！），忽然想起以前曾经有几次观察过调用堆栈的事情。于是，抓紧时间试一下，果然成功－－－－一只很大的BUG被挖出来了！
总结
犯上述错误原因主要在于：代码非常长（近5000行），而且反复修改，有时很多内容无意间修改不完全（这是一种典型的无意间，而且很多人都会出现的错误），导致后期浪费大量时间。
结论之一是：以后多多使用系统提供的“重构”功能（如今的我使用的VS2012集成开发环境这方面支持个人感觉已经非常优秀），甚至对于较长的子函数也尽可能使用，从而最大限度地避免上述问题！（有时候，个人有些骄傲，在较长函数内部修改就不使用“重构”了！正是这种原因导致上述BUG。）
结论之二是：出现系统运行错时，多多使用调用堆栈。如今的调用堆栈能够帮助你最近地靠拢出现BUG的源码处，VERY GOOD！看看我的这个截图吧。
只要双击相应的调用堆栈中那一行，源码立即出现在面前。几乎第一时间就帮助你抓住BUG了！
本文转自朱先忠老师51CTO博客，原文链接： http://blog.51cto.com/zhuxianzhong/1548665，如需转载请自行联系原作者
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
