Answers:
不要承担任何责任
常常说“哦，我知道这段代码在做什么，很好”。不要那样做 测试每个假设，并仔细完成所有步骤。
在浏览一小段代码之前，请查看您是否可以准确确定结果。面对任何不采取任何措施（我赞成，顺便说一句）的做法，这种做法确实会飞起来，但是随着您积累经验，它可以帮助缩小查找范围。
这听起来很琐碎，但要了解调试器的细微差别并了解热键。有时，调试器的运行速度可能会很慢，以至于您单步执行时会感到疑惑。如果您可以跟上机器的进度并且不停地乱逛，那将会有所帮助。
如果您可以在调试时修改代码：
喜欢：
bool isLessThan5 = a < 5;
bool isGreaterThan10 = a > 10;
if ( isLessThan5 || isGreaterThan10 )
{
// more code here
}
代替：
if ( a < 5 || a > 10 )
{
// more code here
}
对于这种情况，无论出于何种原因您都无法调试所有内容，请与同事一起学习“橡皮鸭式”。有时，解释的行为会引起人们的注意。（好的，也许这不是问题主题，但我认为它已经足够值得提及）
基于过去22年中大部分时间用于维护他人编写的代码的两件事。
了解您倾向于编写的各种错误。
例如，我是一个非常细致的编码器，因此一旦我的代码编译完毕，它通常就不会出现一些小错误。因此，我的错误通常是诸如线程死锁之类的复杂事物。另一方面，我有一个朋友，他主要编写一些琐碎的错误-在C ++的循环末尾使用分号，因此下一行仅执行一次，这种事情。
不要以为别人会写和你一样的错误。
我不知道我浪费了很多时间抽出大型调试枪，假设一个错误是我那种非常微妙的怪异事物，只是让我的朋友看着我的肩膀走了，“你注意到了吗？分号？” 经过多年的努力，当我着眼于其他人的代码时，我首先尝试了一些琐碎，低落的成果。
了解您的工具。例如，Visual Studio的调试器具有一个称为TracePoints的强大功能，它类似于断点，但不是停止代码而是将trace语句插入调试输出中。
强烈建议您阅读书籍或参加有关如何使用调试器的课程。我上了几节课，读了约翰·罗宾斯（John Robbins）的几本书，这对我作为调试器的有效性产生了很大的影响。
查阅Andreas Zeller 撰写的非常有价值的书《为什么程序失败：系统调试指南》。它将向您介绍许多技术，理论和工具，其中一些处于研究的前沿。
该书的幻灯片可在线获得，但我发现该书本身更易于阅读。
这本书将帮助您入门，并使您对调试进行更科学的思考，但是它不能替代实践。您可能需要进行10年的编写和调试工作，然后才能看到性能上的数量级提高。我仍然记得在Sun见到我时曾大吃一惊，看到高级程序员已经为Unix编程了30年，他们在几分钟之内就发现了晦涩的多线程或并行错误。经验很重要！