A股上市公司传智教育(股票代码 003032)旗下技术交流社区北京昌平校区

 找回密码
 加入黑马

QQ登录

只需一步,快速开始

© wzboy 中级黑马   /  2015-4-28 14:15  /  1897 人查看  /  4 人回复  /   0 人收藏 转载请遵从CC协议 禁止商业使用本文

        当程序出毛病的时候,立刻停止正在做的任何操作。不要按任何按钮。仔细地看一下屏幕,注意那些不正常的地方,记住它或者写下来。然后慎重地点击 “确定” 或“取消”,选择一个最安全的。学着养成一种条件反射——一旦电脑出了问题,先不要动。要想摆脱这个问题,关掉受影响的程序或者重新启动计算机都不好,一个解决问题的好办法是让问题再次产生。程序员们喜欢可以被重现的问题,快乐的程序员可以更快而且更有效率的修复bug。
“我想粒子的跃迁与错误的极化有关”
并不只是非专业的用户才会写出拙劣的bug报告,我见过一些非常差的bug报告出自程序员之手,有些还是非常优秀的程序员。
有一次我与另一个程序员一起工作,他一直在找代码中的bug,他常常遇到一个bug,但是不会解决,于是就叫我帮忙。“出什么毛病了?”我问。而他的回答却总是一些关于bug的意见。如果他的观点正确,那的确是一件好事。这意味着他已经完成了工作的一半,并且我们可以一起完成另一半工作。这是有效率并有用的。
但事实上他常常是错的。这就会使我们花上半个小时在原本正确的代码里来回寻找错误,而实际上问题出在别的地方。我敢肯定他不会对医生这么做。“大夫,我得了Hydroyoyodyne(真是怪病——译者),给我开个方子”,人们知道不该对一位医生说这些。您描述一下症状,哪个地方不舒服,哪里疼、起皮疹、发烧……让医生诊断您得了什么病,应该怎样治疗。否则医生会把您当做疑心病或精神病患者打发了,这似乎没什么不对。
做程序员也是一样。即便您自己的“诊断”有时真的有帮助,也要只说“症状”。“诊断”是可说可不说的,但是“症状”一定要说。同样,在bug报告里面附上一份针对bug而做出修改的源代码是有用处的,但它并不能替代bug报告本身。
如果程序员向您询问额外的信息,千万别应付。曾经有一个人向我报告bug,我让他试一个命令,我知道这个命令不好用,但我是要看看程序会返回一个什么错误(这是很重要的线索)。但是这位老兄根本就没试,他在回复中说“那肯定不好用”,于是我又花了好些时间才说服他试了一下那个命令。
多动动脑筋对程序员是有帮助的。即使您的推断是错误的,程序员也应该感谢您,您的尝试使他们的工作变的更简单。不过千万别忘了报告“症状”,否则只会使事情变得更糟。
“真是奇怪,刚才还不好用,怎么现在又好了?”
“间歇性错误”着实让程序员发愁。相比之下,进行一系列简单的操作便能导致错误发生的问题是简单的。程序员可以在一个便于观察的条件下重复那些操作,观察每一个细节。太多的问题在这种情况下不能解决,例如:程序每星期出一次错,或者偶然出一次错,或者在程序员面前从不出错(程序员一离开就出错。——译者)。当然还有就是程序的截止日期到了,那肯定要出错。
大多数“间歇性错误”并不是真正的“间歇”。其中的大多数错误与某些地方是有联系的。有一些错误可能是内存泄漏产生的,有一些可能是别的程序在不恰当的时候修改某个重要文件造成的,还有一些可能发生在每一个小时的前半个小时中(我确实遇到过这种事情)。
同样,如果您能使bug重现,而程序员不能,那很有可能是他们的计算机和您的计算机在某些地方是不同的,这种不同引起了问题。我曾写过一个程序,它的窗口可以蜷缩成一个小球停在屏幕的左上角,它在别的计算机上只能在800×600解析度工作,但是在我的机器上却可以在1024×768工作。
程序员想要了解任何与您发现的问题相关的事情。有可能的话您到另一台机器上试试,多试几次,两次,三次,看看问题是不是经常发生。如果问题出现在您进行了一系列操作之后,不是您想让它出现它就会出现,这就有可能是长时间的运行或处理大文件所导致的错误。程序崩溃的时候,您要尽可能的记住您都做了些什么,并且如果您看到任何图形,也别忘了提一下。您提供的任何事情都是有帮助的。即使只是概括性的描述(例如:当后台有EMACS运行时,程序常常出错),这虽然不能提供导致问题的直接线索,但是可能帮助程序员重现问题。
最重要的是:程序员想要确定他们正在处理的是一个真正的“间歇性错误”呢,还是一个在另一类特定的计算机上才出现的错误。他们想知道有关您计算机的许多细节,以便了解您的机器与他们的有什么不同。有许多细节都依仗特定的程序,但是有一件东西您一定要提供——版本号。程序的版本、操作系统的版本以及与问题有关的程序的版本。
“我把磁盘装进了我的Windows……”
表意清楚在一份bug报告里是最基本的要求。如果程序员不知道您说的是什么意思,那您就跟没说一样。我收到的bug报告来自世界各地,有许多是来自非英语国家,他们通常为自己的英文不好而表示歉意。总的来说,这些用户发来的bug报告通常是清晰而且有用的。几乎所有不清晰的bug报告都是来自母语是英语的人,他们总是以为只要自己随便说说,程序员就能明白。
精确:
如果做相同的事情有两种方法,请说明您用的是哪一种。例如:“我选择了‘载入’”,可能意味着“我用鼠标点击‘载入’”或“我按下了‘ALT+L’”,说清楚您用了哪种方法,有时候这也有关系。
详细:
信息宁多毋少!如果您说了很多,程序员可以略去一部分,可是如果您说的太少,他们就不得不回过头再去问您一些问题。有一次我收到了一份bug报告只有一句话,每一次我问他更多事情时,他每次的回复都是一句话,于是我花了几个星期的时间才得到了有用的信息。
谨慎使用代词:
诸如“它”,“窗体”这些词,当它们指代不清晰的时候不要用。来看看这句话:“我运行了FooApp,它弹出一个警告窗口,我试着关掉它,它就崩溃了。”这种表述并不清晰,用户究竟关掉了哪个窗口?是警告窗口还是整个FooApp程序?您可以这样说,“我运行FooApp程序时弹出一个警告窗口,我试着关闭警告窗口,FooApp崩溃了。”这样虽然罗嗦点,但是很清晰不容易产生误解。
检查:
重新读一遍您写的bug报告,您觉得它是否清晰?如果您列出了一系列能导致程序出错的操作,那么照着做一遍,看看您是不是漏写了一步。
小结:
bug报告的首要目的是让程序员亲眼看到错误。如果您不能亲自做给他们看,给他们能使程序出错的详细的操作步骤。
如果首要目的不能达成,程序员不能看到程序出错。这就需要bug报告的第二个目的来描述程序的什么地方出毛病了。详细的描述每一件事情:您看到了什么,您想看到什么,把错误消息记下来,尤其是“错误消息号”。
当您的计算机做了什么您料想不到的事,不要动!在您平静下来之前什么都别做。不要做您认为不安全的事。
尽量试着自己“诊断”程序出错的原因(如果您认为自己可以的话)。即使做出了“诊断”,您仍然应该报告“症状”。
如果程序员需要,请准备好额外的信息。如果他们不需要,就不会问您要。他们不会故意为难自己。您手头上一定要有程序的版本号,它很可能是必需品。
表述清楚,确保您的意思不能被曲解。
总的来说,最重要的是要做到精确。程序员喜欢精确。
本文来源
Copyright(C) 2001 by Eric S. Raymond
中文版Copyleft 2001 by D.H.Grand(nOBODY/Ginux)
英文版:http://www.tuxedo.org/~esr/faqs/smart-questions.html
感谢Eric的耐心指点和同意,本文才得以完成并发布
本指南英文版版权为Eric Steven Raymond 所有
中文版版权由D.H.Grand[nOBODY/Ginux]所有
最后,不管是谁,来这里回答问题都是凭一腔热忱,凭兴趣和心情,如果版面充斥让人没有兴趣回答的问题,我想,对大家都不是好消息。自力更生真的很重要,不管你水平如何遇到什么样的困难,能自己解决多少就解决多少,然后再来求助,说需要什么什么帮助,多做一些努力只有好处没有坏处,问一个好问题并不比问一个坏问题困难多少。

4 个回复

倒序浏览
遇到报错不要怕,一步一步debug
回复 使用道具 举报
遇到问题要学会冷静,不要慌张
回复 使用道具 举报
很赞~~~
回复 使用道具 举报
很好 顶一下啊!
回复 使用道具 举报
您需要登录后才可以回帖 登录 | 加入黑马