盘点那些调试过程中不可不知的方法论

代码调试和bug修复是每个程序员不得不打磨的基本技能,在工作中至关重要。掌握相应的调试方法论能够大幅的提升调试效率,防止在工作过程中走弯路。这里盘点一下调试过程中需要掌握的方法论,希望对你有所帮助。

规则1 理解业务系统

1.如果你是在排查一个相对比较陌生的系统,一定要认真阅读文档和说明,了解对应的业务流程,防止自己的操作破坏系统。记住理解系统是不破坏系统的第一步。

2.了解系统之后要甄别现象,确定哪种现象是异常的,不要把正常现象列为bug.

3.熟悉你的调试工具,知道哪些事情工具可以帮你做,哪些事情工具做不到(可以到官网去了解看一下对应的IDE的最新特性)。

规则2 复现问题

最好能复现对应的bug现象,记录下来bug复现的步骤。这样你才能校验,你的修改到底是不是修复了对应的问题。

到bug发生的机器上去排查,不要试图在一个全新的机器上去模拟bug,因为很多bug是跟具体的机器的硬件环境和软件环境相关联的。

针对偶现的bug,你要多观察,找到偶现的bug发生的一些特征。执行了哪些操作,在哪些硬件上发生,通过特征去分析bug发生的原因,很多时候可能是你不留意的一些因素导致了问题的发生。

排查问题的时候,一定不要武断,认为很多低级问题不会发生。我在排查问题的时候,就遇到过很多低级的问题,比如,程序没启动,没有配置服务器地址,没有联网,没有开机等等你想都想不到的问题。

规则3 不要臆测,要根据证据推断

凭空想象，问题可能有几千条原因。而实际的原因只有去看了才能发现。在调试的时候,要看控制台的输出内容以及对应的报错信息,还有就是要看相关程序的日志。只有这样判断才是有根据的,在不了解任何情况下,盲目下的判断,大概率是有问题的。

观察错误信息

错误信息可以是编译过程中输出的错误警告,运行时终端输出的提示信息,以及任务执行过程中出现的日志。当然运行过程中出现的异常现象,比如CPU异常占用,内存占用持续增高等都是错误相关联的信息。通过错误信息,加上对应的业务流程的变化,我们就可以大致的明确排查方向,避免走弯路。

记住,每一个排查方向的确定,都是依据现有的证据确定的,而不是臆测的。亲眼看到底层的失败是非常重要的，如果你猜测失败是如何发生的，那常常会修复一些根本不是bug的问题，这样的修复不仅不会解决问题，而且还会浪费时间和金钱，甚至会破坏其它的地方。请记住，不要这样做。

一定要善于利用工具

现在的问题调试工具有很多,包括内存分析工具、程序分析工具、代码检查工具以及日志分析工具等等。通过合理组合利用各种问题分析工具,我们可以很容易的发现一些异常现象。这样很容易帮助我们排查和定位对应的问题。

在开发的过程中,我们也可以给各种入口和功能添加对应的指标和检测,将一些调试功能嵌入正常的业务,这样可以为我们的后续排查提供很多便利。当然不要因为调试功能影响了正常的业务。

规则4 分而治之

当bug的藏身之地不断被缩小一半时，它将很难再隐藏下去。分而治之是调试的核心。

通过逐次逼近缩小搜索范围,找到对应的目标。任何有效的目标搜索都会使用一种共同的技术，那就是“逐次逼近”（successiveapproximation)(二分查找)他通过反复地把问题分成好的一半和坏的一半，来缩小搜索范围，然后进一步研究有问题的那一半。

分而治之的时候首先确定问题的出现范围,然后通过问题的上下游确定自己处于bug的哪一侧。通过添加比较易于观察和检测的调试信息,一步步调试搜索确定问题出现的位置。如果发现了问题要马上修复,很多时候bug之间是相互保护相互隐藏的,可能你修复了一个问题其它的问题也莫名其妙的就被解决了。记住发现了问题要马上解决,别留着。

排查问题的时候首先要排出各种干扰因素,常见的问题有杀毒软件、防火墙等等。这里首先要提一下360,如果你的软件没有经过360审核通过的话,在使用过程中很有可能受到它的拦截影响正常的业务。但对一些无足轻重的问题不要过于极端，也不要为了追求完美而去修改所有地方。

规则5 一次只改一个地方

不要让我们的修改遮盖了原有问题或者引发新的问题。我们在生活中要有一点先见之明。如果你所做的更改没有起到预期的作用，那么就把它改回来。它们可能会产生无法预料的影响。

在没有了解具体的情况的时候,先沉下心来了解情况,不要试图马上开始修改排查,防止自己的修改引发更严重的问题。排查问题的时候,针对性的修改关键因素,隔离和控制其它无关或已经知道的因素,防止引入其它因素的影响,扰乱排查方向。

如果所有出错的情况都有一些特征，而这些特征是正常情况所没有的，那么你就找到了问题所在。在排查的时候你必须把它们之间的差别减少到只与bug有关。排除其他的干扰因素。试着从相同机器的连续测试中获取调试记录，不要使用不同的机器、软件、参数、用户输入，也不要在不同的时间和不同的环境下进行测试。通过统计分析软件的错误特征,你能得到很有价值的线索。这对定位和解决问题是很重要的。

确定自从上一次正常工作以来你改变了什么地方。

有时，正常的系统和错误的系统之间的区别是由于一项更改造成的。做了更改之后，正常的系统开始出现故障。一种非常有效的办法是找出第一个导致系统出错的版本，尽管这可能需要连续测试原来的版本，直到找到没有故障的版本。一旦找到了这个版本，再前进到下一个版本，验证故障是否再次出现。做完这一步之后，至少可以把问题的范围限定到两个版本之间所做的修改。当然，你得有一个完备的源设计跟踪系统，这样就可以快速查看所有任何两个版本之间的所有区别。假设你所做的修改不是对系统进行全面的大幅度修改，这种方法将使你更容易找到问题。

规则6 保持日志操作跟踪

写代码的时候写日志记录操作步骤顺序和结果很重要,通过日志确定用户的操作记录,你可以很快的排查出应该关注的重点是哪一步,能极大的提升调试的效率。

调试的时候, 要知道，任何细节都可能是重要的。关键是在记录调试跟踪日志的同时，也要把那些没在日志中出现的所有条件和症状记录下来。如果你能把症状和时间戳记下来就更好了。

调试的时候你必须记录下每一件事情，不起眼的事情可能会很重要。记下你的每步操作、顺序和结果在细节方面，永远都不要相信你的记忆，而要把它写下来。如果你相信你的记忆，将会制造很多麻烦。你会忘掉一些你认为不重要的细节，当然，这些细节将会被证明是非常重要的。

规则7 检查基本的东西

一些显而易见的假设往往是错误的,很多问题的出现,都是很低级的问题。记住这句话。

很多时候我们都会假设用户正常的使用了软件,软件自己出问题了。这时候我建议你置疑你的假设,先排查确定是不是用户没有正常使用软件引发的问题,可能你会有意想不到的收获。

软件被启动了吗?

软件是否被正常配置了?

电脑是否联网了?

输入的数据是否正确?

很多时候问题更可能发生在我所说的那些“一般性”或“基础性”元素上。由于它们都是一些基本需求(电力供应、联网通信、正常配置), 因此当你对一些细节进行调试的时候往往会忽略它们。永远不要相信自己的假设，特别是当这些假设在一些无法解释的问题中是核心因素的时候。应该问自己一个古老的、看似愚蠢的问题：“你重启了吗?”。

通常，问题发生在较低的层次上。你可能奇怪为什么一个复杂的数字芯片无法正确工作，而你却没有查看一下是否为它提供了电源。它有时钟吗?假设你的图形硬件不工作了，应该检查以下问题：系统是否安装了正确的图形驱动程序?你是否运行了正确的操作系统?注册表中是否启用了这项功能?甚至还应该考虑是否运行了你要运行的代码?人们经常会说“这段新代码运行起来与原来的代码一模一样。”随后却发现实际上根本就没有载入新代码。你只是载入了旧代码，或者是载入了新代码，但系统仍然执行了旧代码，原因是你没有重启计算机，或者系统留下了一个很容易找到的旧代码的副本。

还有一点要注意你使用的工具也有可能出问题,不要忘记对工具进行测试。之前出现过IDE没法编译新代码的问题,不管怎么编译都是运行的旧代码,重启一下就好了。

规则8 多于别人沟通交流征求意见

有时候将问题描述给别人听,能够帮助你认识到你先之前没有注意到的事情。梳理问题的头绪，最好的方法就是把它讲给别人听。

向别人寻求帮助至少有3个原因：

1.可以获得全新观点

2.能获得专业知识和经验。

3.人们通常很愿意帮忙，因为这给了他们一个证明自己很聪明的机会。

我们按照自己老一套的思路是很难看清全局的。我们都是普通人，对任何事情都有偏见，包括对bug隐藏在哪里的看法。这些偏见可能导致我们无法看清实际情况。而其他人则会从一个无偏见的角度来看问题(实际上他们只是有另一种不同的偏见)，这可能会给我们很大的启发，帮助找到新的方法。

事实上，有时向别人解释问题也会使你有全新的认识，之后你自己就解决了问题。对事实进行组织的过程迫使你跳出你原来的思维模式。

在任何情况下，专家都比我们更“理解系统”，因此他们知道查找问题的大致路线图，也能够为我们的搜索工作提供很好的提示。当我们找到bug时，他们可以帮助我们设计一个正确的修复方案，以便不会影响系统的其他部分。

可以到哪里获取帮助?

官方文档，论坛，同事，认识的专家

阅读手册，向第三方供应商咨询

咨询问题的时候要放下面子,你可能害怕寻求帮助，你认为这是无能的表现。但事实恰恰相反，这只是表明你急于修复bug。如果你获取了正确的见解、专业知识和经验，将会更快地修复问题。这并不会暴露你的弱点，如果真的要说有什么的话，也只是说明你明智地选择了帮助。

在向别人描述问题的时候，一定要记住一件事：报告现象和症状，而不要讲你的理论。之所以要从别人那里获得全新的观点，就是因为你的理论起不到任何作用。如果你找了一个人，把你的理论告诉他，那么也会把他拉到你原来的思维定式中。同时，你很有可能会把一些需要让他知道的关键细节隐藏起来了，因为你自己有偏见，认为这些细节不重要。因此一定要注意这一点。当寻求帮助时，描述发生的事情，描述你看到的一切。如果有可能，还要把条件描述清楚。告诉别人什么事情是间歇发生的，什么事情不是。

让他提出自己的观点，他们的观点可能和你的观点相符，也可能不同，而这正是你想要的。

有一些地方属于不好判断的“灰色地带”。有时你可能注意到一些数据看起来很别扭，像是错误的，或者与问题有某种关系，但你不确定为什么会这样。这些地方是值得提出来的，事实是你发现了一些出乎意料或不理解的事情。它可能与问题无关，但至少是有用的信息。

规则9 如果你不修复bug，它将依然存在

当危险已经离你很近时，拒绝承认它并不是勇敢的表现，而是愚蠢。

当问题被修正了之后,采用可以检验的方式确认问题确实被修复了,检查修正方案的准确性,确定确实是自己的解决方案解决了问题。

要知道，bug从来不会自己消失,使用最初复现问题的的方法再次复现问题,确定问题不再发生。

发现问题之后,挖掘深层次的原因,确定问题出流程中存在的错误和异常,通过健全流程和制度从根本上杜绝相应问题的出现。