【昊昊带你学】DEBUG

**************************转载请注明出处！******************************

         本周带大家了解一下Bug,Debug。这次还要特别强调一下，大神神马的你爱看就看，不爱看滚粗。不要转我们这些菜的日志秀优越。

 “BUG”的由来

　　Bug一词的原意是“臭虫”或“虫子”。但是现在，在电脑系统或程序中，如果隐藏着的一些未被发现的缺陷或问题，人们也叫它“bug”，这是怎么回事呢？

　　原来，第一代的计算机是由许多庞大且昂贵的真空管组成，并利用大量的电力来使真空管发光。可能正是由于计算机运行产生的光和热，引得一只小虫子（Bug）钻进了一支真空管内，导致整个计算机无法正常工作。研究人员费了半天时间，总算发现原因所在，把这只小虫子从真空管中取出后，计算机又恢复正常。后来，Bug这个名词就沿用下来，用来表示电脑系统或程序中隐藏的错误、缺陷、漏洞等问题。

　　1947年，计算机还是由机械式继电器和真空管驱动的，机器有房间那么大。体现当时技术水平的MarkⅡ，是由哈佛大学制造的一个庞然大物。当技术人员正在进行不整机运行时，它突然停止了工作。他们爬上去找原因，发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾，这显然是由于飞蛾受光和热的吸引，飞到了触点上，然后被高电压击死。

　　与Bug相对应，人们将发现Bug并加以纠正的过程叫做“Debug”(中文称作“调试”），意即“捉虫子”或“杀虫子”。

后来就直接用bug 在现在很多的软件测试中 都用Bug来说明那些问题。（粘自百度百科）

所谓“（Bug）”，是指电脑系统的硬件、系统软件（如操作系统）或应用软件（如文字处理软件）出错。硬件的出错有两个原因，一是设计错误，一是硬件部件老化失效等。软件的Bug，狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。

 

         IDE（比如codeblocks）会提供debug的功能，主要功能:

 

         设置断点——设置一个端点，调试的时候运行到端点停止

单步调试——一行一行地执行你编的程序

一些监视工具，可以看到各种变量、系统栈等的状态。

 

下面，我来说说自己debug的一点心得吧，优越狗继续滚粗。首先要切记一点，有许多好的编程习惯，可以很好地把许多bug和错误扼杀在摇篮里。比如（b == 0）写成（0 == b）；比如变量初始化。这些能做在前面的大家不要犯懒。然后才是真正debug的阶段。

首先，很多刚接触编程的同学，甚至有很多已经学这个专业很久的学长，可能都不太重视debug，这个意识可能也很薄弱。首先，不说别的，就说ACM题这样结构简单的程序。有很多人，编完程序，一跑。我嘞个擦，哥改了半天终于能运行了，尼玛你怎么敢输出个错误的结果~！@#￥%……&*（）——）（*@！~这时候可能就已经没有耐心了。或者说，想调已经无从下手了。

首先，debug的工具你要使用。一种是IDE给你提供的单步调试，断点，监控之类的工具。而另一种，也是更为灵活的一种就是输出一些调试信息。我个人喜欢后者。前者虽然很方便，但是不可避免的，它比较死板，而且很多时候会出各种bug。比如你在函数里来回跳啊跳。一些不给力的IDE就搞不定了。而输出调试信息，你可以根据自己的需要输出。当然，这因人而异，萝卜白菜各有所爱吧。

其次，就是debug的过程。一般对于算法题这样规定输入输出格式的问题来说。你要现看看是不是因为格式问题而导致问题的出现。对于我来说，我会把读入的变量整体输出，对照输入看看是否正确。而对于输出问题，如果你看答案是对的，还是不能通过的话，多半是空格神马的不符合说明。如果排除了输入的问题，剩下的就要因题而异了。如果运行之后，无法停止，那多半是有某些边界条件无法达到（当然也有可能是你的算法太屎），导致时间很久。你可以输出一些调试信息，找出死循环的位置。估计这种错误多半是你忘记修改循环变量的值了。当然也有时候是边界条件设错而导致无法达到条件。根据具体情况修改。如果运行之后，出现了一些跟内存有关的错误，就要看看，是否哪的边界条件没有设好。导致数组越界之类的错误。这时候往往程序运行终止的地方就是出错的地方。用debug工具的话，单步调试应该是会停留在出错的地方。很方便就能找到错在哪，如果用输出调试信息的话，你可以在一些地方输出一些函数名之类的信息，标记一下。总之，先找出错误位置。然后你就要关注，具体出错的变量。讲错误与正确的结果对比，来排除某些逻辑上的错误。把这些错误搞定之后，就进入了下一个阶段。程序大体上按照你的思路去走了。如果你的算法正确，到这一步一般就OK了。如果这时候还是不对，那就可能是算法出了错误。这里就只能靠你自己的经验去寻找 自己算法的bug了。这里的bug才是真正的“BUG”！！

一些简单的数据得到正确结果之后，不要随随便便就相信自己的程序已经完美了。你可以设计一些恶心的数据，看看自己的程序有没有新的BUG。或者，你随机生成一系列数据看是否能通过。ACM比赛，为了保证正确反映参赛选手提交程序的好坏。测试数据往往都是经过精心设计的。而实际生活中也一样，你程序的好坏，是会得到用户检验的。BUG难免会存在，但是你要在“生产”环节尽量减少。也就是要对自己的代码负责。

对于大型的工程，debug已经不能靠一些传统的方法来进行了。都有一些成体系的方法。不过我也不是很清楚。只能说说自己调算法题的心得。

训练debug的能力，其实没有什么好的方法。就是自己多见一些BUG，多积累一些经验。最重要的是自己的态度。如果你潜意识里，就没想搞定某个BUG，或者觉得自己肯定搞不定。那肯定没戏，我看了我们组很多学弟学妹的代码。他们有可能只把编译器提示的错误改正了，发现能运行了，就提交当作业了。代码经常漏洞百出。刚开始很正常，我希望随着学习的深入，他们能够逐渐认识到debug的时候应该抱有的态度。也希望他们的程序写的越来越好~~