转载请注明来源:http://blog.csdn.net/horkychen
解bug应当是修复代码中的缺陷，而不只是隐藏起来!
(译注 ：解Bug时常发生分析时总感觉快找到答案了，而后面却一再陷入僵局。比如，将线程同步问题引起的一些时而有，时而没有的问题。分析时可能会认为这是个典型的线程同步问题，A线程没有按照预期的方式改变某个变量，导致了B线程处理出错。这样的分析结果如果没有调试(Debug)的支持，就有可能将开发者带入死胡同，找出一大堆的解决方案可能都无法完整地解掉Bug。一定要在每次陷入困境的时候，回头想一想，还有没有什么被忽略了。在一开始就对问题进行充分的了解是十分必要的。下文中作者提供了一个简单的流程可供参考。)
图片来源:http://www.phptechie.com
原文:http://forums.mtgsalvation.com/blog.php?b=3108
过去两年工作中，我竟然成了一个擅长解Bug的家伙。真不知道为什么偏偏是解Bug成了自然而然的事。在这段时间里我总结出了一套解bug的流程，简称为RED方法吧(译注:感 觉可以像是红色警戒!)。不过，这也不是什么新的方法论了。事实上，它成为标准的软件开发实践已经有些年头了。但是我依然见到许多开发者无法系统运用这个方法，总是被解Bug弄得头大。这就是写这篇文章的原因。
RED方法是什么？它其实上就是三个步骤： 重现(Reproduce)，评估(Evaluate)，和调试(Debug)。这三个步骤已经让我能够快速识别Bug的来源并快速的除掉它。c以下是详细的步骤：
重现(Reproduce)
重现一个 bug，除了验证它确实存在，也是为了找到一个测试用例供解决时使用。能够自信地测试您的解决方案对确保解掉这个bug 至关重要。(译注:常常有程序员看到Bug描述，就想当然的认为如何如何，结果可与之相反，这样的状况屡见不鲜。重现是第一步，特别是理解Bug背后的意图，就像是软件开发中的需求之于设计一样重要。)
评估(Evaluate)
面对Bug, 大多数开发者会将时间花在这里。坦率地说，这是错误的。评估应当用于找出一些显而易见的问题 （错误字符、 错误的常量等），然后调试程序，这样可以快速从代码中隔离出来这个Bug。解bug需要更多地关注代码。评估很重要，但不能靠它来解掉bug。
调试(Debug)
这是最重要的一步。一旦确定了Bug出现的位置，就要以单步执行的方式跟踪代码并加以分析。Bug 往往更多地取决于程序的状态，而不是它的位置。如果一个Bug发生是因为某个不应该为NULL的变量却赋成了NULL，那么这个Bug的根本原因可能在此位置之前了。(代码死掉的位置并不一定是Bug存在的位置)。
代码的运行状态比代码本身更重要。运用调试可以让你真正了解程序的运行状态。一行一行地逐步执行程序可以最终发现您的代码在哪里出错了和什么状态导致了这个问题。只有了解了代码为什么出错，而不是只了解代码在什么位置出错，才能找出最佳的解决方案。
例如，刚刚提到的那个Bug可以有两种方案：
1. 添加判断，以确认该变量不是NULL。
2. 消除所有可能导致此变量为NULL值的情况。
第一种方法有时可能是正确的。但如果在设计时该变量无论在哪里都不应为空，那这样做就有问题了。这样做只会暂时掩饰掉它，而以后可能就要花更多的时间来解决变量为NULL的情况了。
如果先确定导致该变量为NULL的所有情况，对于先前的设计，消除掉这些异常的情况，这样才算真正解掉了这个bug。解bug应当是修复代码中的缺陷，而不只是隐藏起来。
(译注：我比较推荐习惯用思维导图的方式来思考，避免思维障碍，并具有普遍怀疑的精神。在软件这个行当，主观经验是经常骗人的!
(参考<<软件开发之韵>> 2.3经验式管理)
另一个有价值的参考:
Avoid Side Effects
)
转载请注明来源:http://blog.csdn.net/horkychen
解bug应当是修复代码中的缺陷，而不只是隐藏起来!
(译注 ：解Bug时常发生分析时总感觉快找到答案了，而后面却一再陷入僵局。比如，将线程同步问题引起的一些时而有，时而没有的问题。分析时可能会认为这是个典型的线程同步问题，A线程没有按照预期的方式改变某个变量，导致了B线程处理出错。这样的分析结果如果没有调试(Debug)的支持，就有可能将开发者带入死胡同，找出一大堆的解决方案可能都无法完整地解掉Bug。一定要在每次陷入困境的时候，回头想一想，还有没有什么被忽略了。在一开始就对问题进行充分的了解是十分必要的。下文中作者提供了一个简单的流程可供参考。)
图片来源:http://www.phptechie.com
原文:http://forums.mtgsalvation.com/blog.php?b=3108
过去两年工作中，我竟然成了一个擅长解Bug的家伙。真不知道为什么偏偏是解Bug成了自然而然的事。在这段时间里我总结出了一套解bug的流程，简称为RED方法吧(译注:感 觉可以像是红色警戒!)。不过，这也不是什么新的方法论了。事实上，它成为标准的软件开发实践已经有些年头了。但是我依然见到许多开发者无法系统运用这个方法，总是被解Bug弄得头大。这就是写这篇文章的原因。
RED方法是什么？它其实上就是三个步骤： 重现(Reproduce)，评估(Evaluate)，和调试(Debug)。这三个步骤已经让我能够快速识别Bug的来源并快速的除掉它。c以下是详细的步骤：
重现(Reproduce)
重现一个 bug，除了验证它确实存在，也是为了找到一个测试用例供解决时使用。能够自信地测试您的解决方案对确保解掉这个bug 至关重要。(译注:常常有程序员看到Bug描述，就想当然的认为如何如何，结果可与之相反，这样的状况屡见不鲜。重现是第一步，特别是理解Bug背后的意图，就像是软件开发中的需求之于设计一样重要。)
评估(Evaluate)
面对Bug, 大多数开发者会将时间花在这里。坦率地说，这是错误的。评估应当用于找出一些显而易见的问题 （错误字符、 错误的常量等），然后调试程序，这样可以快速从代码中隔离出来这个Bug。解bug需要更多地关注代码。评估很重要，但不能靠它来解掉bug。
调试(Debug)
这是最重要的一步。一旦确定了Bug出现的位置，就要以单步执行的方式跟踪代码并加以分析。Bug 往往更多地取决于程序的状态，而不是它的位置。如果一个Bug发生是因为某个不应该为NULL的变量却赋成了NULL，那么这个Bug的根本原因可能在此位置之前了。(代码死掉的位置并不一定是Bug存在的位置)。
代码的运行状态比代码本身更重要。运用调试可以让你真正了解程序的运行状态。一行一行地逐步执行程序可以最终发现您的代码在哪里出错了和什么状态导致了这个问题。只有了解了代码为什么出错，而不是只了解代码在什么位置出错，才能找出最佳的解决方案。
例如，刚刚提到的那个Bug可以有两种方案：
1. 添加判断，以确认该变量不是NULL。
2. 消除所有可能导致此变量为NULL值的情况。
第一种方法有时可能是正确的。但如果在设计时该变量无论在哪里都不应为空，那这样做就有问题了。这样做只会暂时掩饰掉它，而以后可能就要花更多的时间来解决变量为NULL的情况了。
如果先确定导致该变量为NULL的所有情况，对于先前的设计，消除掉这些异常的情况，这样才算真正解掉了这个bug。解bug应当是修复代码中的缺陷，而不只是隐藏起来。
(译注：我比较推荐习惯用思维导图的方式来思考，避免思维障碍，并具有普遍怀疑的精神。在软件这个行当，主观经验是经常骗人的!
(参考<<软件开发之韵>> 2.3经验式管理)
另一个有价值的参考:
Avoid Side Effects
)