一篇写给程序员的提问艺术（转）

做为一个刚入it界的php菜鸟，我感受本身须要学不少程序员的基本素养，学习如何学习，有效率的学习，精确地学习，热情的学习，加油，

这是一篇关于提问的文章分享给你们吧，

 

（2009年的更新：本文来自2005年的白云黄鹤BBS，未经排版，四年来，文末一直保留有英文原文出处并注明连接）

这个版上太多的问题，不能让我以很愉快的心情来解答，因而，我放弃了强忍着指责别人的心情找到了这篇《提问的艺术》（两年前我在HomePage版张贴过），真诚的但愿那些又困难又指望获得帮助的新手朋友们抽时间看看，问“好的问题”，收获“好的答案”，这对改善答题人的心情和造成版面氛围都有好处。

提问以前

在经过电邮、新闻组或者聊天室提出技术问题前，检查你有没有作到：

1. 通读手册，试着本身找答案。
2. 在FAQ里找答案（一份维护得好的FAQ能够一应俱全:）。
3. 在网上搜索（我的推荐google~~~）。
4. 向你身边精于此道的朋友打听。

当你提出问题的时候，首先要说明在此以前你干了些什么；这将有助于树立你的形象：你不是一个妄图坐享其成的乞讨者，不肯浪费别人的时间。若是提问者能从答案中学到东西，咱们更乐于回答他的问题。

周全的思考，准备好你的问题，草率的发问只能获得草率的回答，或者根本得不到任何答案。越表现出在寻求帮助前为解决问题付出的努力，你越能获得实质性的帮助。

当心别问错了问题。若是你的问题基于错误的假设，普通黑客（J. Random Hacker）一般会用无心义的字面解释来答复你，内心想着“蠢问题…”，但愿着你会从问题的回答（而非你想获得的答案）中汲取教训。

决不要自觉得够资格获得答案，你没这种资格。毕竟你没有为这种服务支付任何报酬。你要本身去“挣”回一个答案，靠提出一个有内涵的，有趣的，有思惟激励做用的问题–一个对社区的经验有潜在贡献的问题，而不只仅是被动的从他人处索要知识–去挣到这个答案。

另外一方面，代表你愿意在找答案的过程当中作点什么，是一个很是好的开端。“谁能给点提示？”、“我这个例子里缺了什么？”以及“我应该检查什么地方？”比“请把确切的过程贴出来”更容易获得答复。由于你显得只要有人指点正确的方向，你就有完成它的能力和决心。

怎样提问
- 谨慎选择论坛

当心选择提问的场合。若是象下面描述的那样，你极可能被忽略掉或者被看做失败者：

1. 在风马牛不相及的论坛贴出你的问题
2. 在探讨高级技巧的论坛张贴很是初级的问题；反之亦然
3. 在太多的不一样新闻组交叉张贴

- 用辞贴切，语法正确，拼写无误

咱们从经验中发现，粗心的写做者一般也是马虎的思考者（我敢打包票）。 回答粗枝大叶者的问题很不值得，咱们宁愿把时间耗在别处。

正确的拼写，标点符号和大小写很重要。

更通常的说，若是你的提问写得象个半文盲，你颇有可能被忽视。

若是你在使用非母语的论坛提问，你能够犯点拼写和语法上的小错–但决不能在思考上马虎（没错，咱们能弄清二者的分别）。

- 使用含义丰富，描述准确的标题

在邮件列表或者新闻组中，大约50字之内的主题标题是抓住资深专家注意力的黄金时机。别用喋喋不休的“帮帮忙”（更别说“救命啊！！！！！”这样让人反感的话）来浪费这个机会。不要妄想用你的痛苦程度来打动咱们， 别用空格代替问题的描述，哪怕是极其简短的描述。

蠢问题： 救命啊！个人膝上机不能正常显示了！

聪明问题： XFree86 4.1下鼠标光标变形，Fooware MV1005的显示芯片。

若是你在回复中提出问题，记得要修改内容标题，代表里面有一个问题。一个看起来象“Re：测试”或者“Re：新bug”的问题很难引发足够重视。另外，引用并删减前文的内容，给新来的读者留下线索。

- 精确描述，信息量大

1. 谨慎明确的描述症状。
2. 提供问题发生的环境（机器配置、操做系统、应用程序以及别的什么）。
3. 说明你在提问前是怎样去研究和理解这个问题的。
4. 说明你在提问前采起了什么步骤去解决它。
5. 罗列最近作过什么可能有影响的硬件、软件变动。

尽可能想象一个黑客会怎样反问你，在提问的时候预先给他答案。

Simon Tatham写过一篇名为《如何有效的报告Bug》的出色短文。强力推荐你也读一读。

- 话不在多

你须要提供精确有效的信息。这并非要求你简单的把成吨的出错代码或者数据彻底转储摘录到你的提问中。若是你有庞大而复杂的测试条件，尽可能把它剪裁得越小越好。

这样作的用处至少有三点。第一，表现出你为简化问题付出了努力，这能够使你获得回答的机会增长；第二，简化问题使你获得有用答案的机会增长；第三，在提炼你的bug报告的过程当中，也许你本身就能找出问题所在或做出更正。

- 只说症状，不说猜测

告诉黑客们你认为问题是怎样引发的没什么帮助。（若是你的推断如此有效，还用向别人求助吗？），所以要确信你原本来本告诉了他们问题的症状，不要加进你本身的理解和推论。让黑客们来诊断吧。

蠢问题： 我在内核编译中一次又一次遇到SIG11错误，我怀疑某条飞线搭在主板的走线上了，这种状况应该怎样检查最好？

聪明问题： 我自制的一套K6/233系统，主板是FIC-PA2007 （VIA Apollo VP2芯片组），256MB Corsair PC133 SDRAM，在内核编译中频频产生SIG11错误，从开机20分钟之后就有这种状况，开机前20分钟内从没发生过。重启也没有用，可是关机一夜就又能工做20分钟。全部内存都换过了，没有效果。相关部分的典型编译记录以下…。

- 按时间顺序列出症状

对找出问题最有帮助的线索，每每就是问题发生前的一系列操做，所以，你的说明应该包含操做步骤，以及电脑的反应，直到问题产生。

若是你的说明很长（超过四个段落），在开头简述问题会有所帮助，接下来按时间顺序详述。这样黑客们就知道该在你的说明中找什么。

- 明白你想问什么

漫无边际的提问近乎无休无止的时间黑洞。最能给你有用答案的人也正是最忙的人（他们忙是由于要亲自完成大部分工做）。这样的人对无节制的时间黑洞不太感冒，所以也能够说他们对漫无边际的提问不大感冒。

若是你明确表述须要回答者作什么（提供建议，发送一段代码，检查你的补丁或是别的），就最有可能获得有用的答案。这会定出一个时间和精力的上限，便于回答者集中精力来帮你，这很奏效。要理解专家们生活的世界，要把专业技能想象为充裕的资源，而回复的时间则是贫乏的资源。解决你的问题须要的时间越少，越能从忙碌的专家口中掏出答案。

所以，优化问题的结构，尽可能减小专家们解决它所须要的时间，会有很大的帮助–这一般和简化问题有所区别。所以，问“我想更好的理解X，能给点提示吗？”一般比问“你能解释一下X吗？”更好。若是你的代码不能工做，问问它有什么地方不对，比要求别人替你修改要明智得多。

- 别问应该本身解决的问题

黑客们老是善于分辨哪些问题应该由你本身解决；由于咱们中的大多数都曾本身解决这类问题。一样，这些问题得由你来搞定，你会从中学到东西。你能够要求给点提示，但别要求获得完整的解决方案。

- 去除无心义的疑问

别用无心义的话结束提问，例如“有人能帮我吗？”或者“有答案吗？”。首先：若是你对问题的描述不很合适，这样问更是多此一举。其次：因为这样问是多此一举，黑客们会很厌烦你–并且一般会用逻辑上正确的回答来表示他们的蔑视，例如：“没错，有人能帮你”或者“不，没答案”。

- 谦逊绝没有害处，并且常帮大忙

彬彬有礼，多用“请”和“先道个谢了”。让你们都知道你对他们花费时间义务提供帮助心存感激。然而，若是你有不少问题没法解决，礼貌将会增长你获得有用答案的机会。

（咱们注意到，自从本指南发布后，从资深黑客处获得的惟一严重缺陷反馈，就是对预先道谢这一条。一些黑客以为“先谢了”的言外之意是事后就不会再感谢任何人了。咱们的建议是：都道谢。）

- 问题解决后，加个简短说明

问题解决后，向全部帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。若是问题在新闻组或者邮件列表中引发了普遍关注，应该在那里贴一个补充说明。补充说明没必要很长或是很深刻；简单的一句“你好，原来是网线出了问题！谢谢你们–Bill”比什么也不说要强。事实上，除非结论真的颇有技术含量，不然简短可爱的小结比长篇学术论文更好。说明问题是怎样解决的，但大可没必要将解决问题的过程复述一遍。除了表示礼貌和反馈信息之外，这种补充有助于他人在邮件列表/新闻组/论坛中搜索对你有过帮助的完整解决方案，这可能对他们也颇有用。最后（至少？），这种补充有助于全部提供过帮助的人从中获得知足感。若是你本身不是老手或者黑客，那就相信咱们，这种感受对于那些你向他们求助的导师或者专家而言，是很是重要的。问题久拖未决会让人灰心；黑客们渴望看到问题被解决。好人有好报，知足他们的渴望，你会在下次贴出新问题时尝到甜头。

- 仍是不懂

若是你不是很理解答案，别马上要求对方解释。象你之前试着本身解决问题时那样（利用手册，FAQ，网络，身边的高手），去理解它。若是你真的须要对方解释，记得表现出你已经学到了点什么。比方说，若是我回答你：“看来彷佛是zEntry被阻塞了；你应该先清除它。”，而后：一个很糟的后续问题： “zEntry是什么？” 聪明的问法应该是这样：“哦~~~我看过帮助了可是只有-z和-p两个参数中提到了zEntry并且还都没有清楚的解释:<你是指这两个中的哪个吗？仍是我看漏了什么？”

三思然后问
如下是几个经典蠢问题，以及黑客在拒绝回答时的心中所想：

问题：我能在哪找到X程序？
问题：个人程序/配置/SQL申明没有用
问题：个人Windows有问题，你能帮我吗？
问题：我在安装Linux（或者X）时有问题，你能帮我吗？
问题：我怎么才能破解root账号/窃取OP特权/读别人的邮件呢？

提问：我能在哪找到X程序？
回答：就在我找到它的地方啊蠢货–搜索引擎的那一头。天呐！还有人不会用Google吗？

提问：个人程序（配置、SQL申明）没有用
回答：这不算是问题吧，我对找出你的真正问题没兴趣–若是要我问你二十个问题才找得出来的话–我有更有意思的事要作呢。

在看到这类问题的时候，个人反应一般不外以下三种：

1. 你还有什么要补充的吗？
2. 真糟糕，但愿你能搞定。
3. 这跟我有什么鸟相关？

提问：个人Windows有问题，你能帮我吗？
回答：能啊，扔掉萎软的垃圾，换Linux吧。

提问：我在安装Linux（或者X）时有问题，你能帮我吗？
回答：不能，我只有亲自在你的电脑上动手才能找到毛病。仍是去找你当地的Linux用户组寻求手把手的指导吧（你能在这儿找到用户组的清单）。

提问：我怎么才能破解root账号/窃取OP特权/读别人的邮件呢？
回答：想要这样作，说明你是个卑鄙小人；想找个黑客帮你，说明你是个ΘΘΘΘ！

好问题，坏问题
最后，我举一些例子来讲明，怎样聪明的提问；同一个问题的两种问法被放在一块儿，一种是愚蠢的，另外一种才是明智的。

蠢问题：我能够在哪儿找到关于Foonly Flurbamatic的资料？

// 这种问法无非想获得“STFW”这样的回答。

聪明问题：我用Google搜索过“Foonly Flurbamatic 2600”，可是没找到有用的结果。谁知道上哪儿去找对这种设备编程的资料？

// 这个问题已经STFW过了，看起来他真的遇到了麻烦。

蠢问题：我从FOO项目找来的源码无法编译。它怎么这么烂？

// 他以为都是别人的错，这个傲慢自大的家伙

聪明问题：FOO项目代码在Nulix 6.2版下没法编译经过。我读过了FAQ，但里面没有提到跟Nulix有关的问题。这是我编译过程的记录，我有什么作得不对的地方吗？

// 他讲明了环境，也读过了FAQ，还指明了错误，而且他没有把问题的责任推到别人头上，这个家伙值得留意。

蠢问题：个人主板有问题了，谁来帮我？

// 普通黑客对这类问题的回答一般是：“好的，还要帮你拍拍背和换尿布吗？” ，而后按下删除键。

聪明问题：我在S2464主板上试过了X、Y和Z，但没什么做用，我又试了A、B和C。请注意当我尝试C时的奇怪现象。显然边带传输中出现了收缩，但结果出人意料。在多处理器主板上引发边带泄漏的一般缘由是什么？谁有好主意接下来我该作些什么测试才能找出问题？

// 这个家伙，从另外一个角度来看，值得去回答他。他表现出了解决问题的能力，而不是坐等天上掉答案。

在最后一个问题中，注意“告诉我答案”和“给我启示，指出我还应该作什么诊断工做”之间微妙而又重要的区别。事实上，后一个问题源自于2001年8月在 Linux内核邮件列表上的一个真实的提问。我（Eric）就是那个提出问题的人。我在Tyan S2464主板上观察到了这种没法解释的锁定现象，列表成员们提供了解决那一问题的重要信息。

经过个人提问方法，我给了你们值得玩味的东西；我让人们很容易参与而且被吸引进来。我显示了本身具有和他们同等的能力，邀请他们与我共同探讨。我告诉他们我所走过的弯路，以免他们再浪费时间，这是一种对他人时间价值的尊重。后来，当我向每一个人表示感谢，而且赞扬这套程序（指邮件列表中的讨论 –译者注）运做得很是出色的时候，一个Linux内核邮件列（lkml）成员表示，问题获得解决并不是因为我是这个列表中的“名人”，而是由于我用了正确的方式来提问。咱们黑客从某种角度来讲是拥有丰富知识但缺少人情味的家伙；我相信他是对的，若是我象个乞讨者那样提问，不论我是谁，必定会惹恼某些人或者被他们忽视。他建议我记下这件事，给编写这个指南的人一些指导。

找不到答案怎么办
若是仍得不到答案，请不要觉得咱们以为没法帮助你。有时只是看到你问题的人不知道答案罢了。没有回应不表明你被忽视，虽然不能否认这种差异很难区分。

总的说来，简单的重复张贴问题是个很糟的想法。这将被视为无心义的喧闹。

你能够经过其它渠道得到帮助，这些渠道一般更适合初学者的须要。有许多网上的以及本地的用户组，由狂热的软件爱好者（即便他们可能从没亲自写过任何软件）组成。一般人们组建这样的团体来互相帮助并帮助新手。

另外，你能够向不少商业公司寻求帮助，不论公司大仍是小（Red Hat和LinuxCare就是两个最多见的例子）。别为要付费才能得到帮助而感到沮丧！毕竟，假使你的汽车发动机汽缸密封圈爆掉了–彻底可能如此– 你还得把它送到修车铺，而且为维修付费。就算软件没花费你一分钱，你也不能强求技术支持老是免费的。

对大众化的软件，就象 Linux之类而言，每一个开发者至少会有上万名用户。根本不可能由一我的来处理来自上万名用户的求助电话。要知道，即便你要为帮助付费，同你必须购买同类软件相比，你所付出的也是微不足道的（一般封闭源代码软件的技术支持费用比开放源代码软件要高得多，且内容也不那么丰富）。

如何有效地报告 Bug
引言

为公众写过软件的人，大概都收到过很拙劣的bug（计算机程序代码中的错误或程序运行时的瑕疵——译者注）报告，例如：

在报告中说“很差用”；
所报告内容毫无心义；
在报告中用户没有提供足够的信息；
在报告中提供了虚假信息；
所报告的问题是因为用户的过失而产生的；
所报告的问题是因为其余程序的错误而产生的；
所报告的问题是因为网络错误而产生的；

这即是为何“技术支持”被认为是一件可怕的工做，由于有拙劣的bug报告须要处理。然而并非全部的bug报告都使人生厌：我在业余时间维护自由软件，有时我会收到很是清晰、有帮助而且内容丰富的bug报告。

在这里我会尽力阐明如何写一个好的bug报告。我很是但愿每个人在报告bug以前都读一下这篇短文，固然我也但愿用户在给我报告bug以前已经读过这篇文章。

简单地说，报告bug的目的是为了让程序员看到程序的错误。您能够亲自示范，也能够给出能致使程序出错的、详尽的操做步骤。若是程序出错了，程序员会收集额外的信息直到找到错误的缘由；若是程序没有出错，那么他们会请您继续关注这个问题，收集相关的信息。

在bug报告里，要设法搞清什么是事实（例如：“我在电脑旁”和“XX出现了”）什么是推测（例如：“我想问题多是出在……”）。若是愿意的话，您能够省去推测，可是千万别省略事实。

当您报告bug的时候（既然您已经这么作了），必定是但愿bug获得及时修正。因此此时针对程序员的任何过激或亵渎的言语（甚至谩骂）都是与事无补的 ——由于这多是程序员的错误，也有多是您的错误，也许您有权对他们发火，可是若是您能多提供一些有用的信息（而不是激愤之词）或许bug会被更快的修正。除此之外，请记住：若是是免费软件，做者提供给咱们已是出于好心，因此要是太多的人对他们无礼，他们可能就要“收起”这份好心了。

“程序很差用”

程序员不是弱智：若是程序一点都很差用，他们不可能不知道。他们不知道必定是由于程序在他们看来工做得很正常。因此，或者是您做过一些与他们不一样的操做，或者是您的环境与他们不一样。他们须要信息，报告bug也是为了提供信息。信息老是越多越好。

许多程序，特别是自由软件，会公布一个“已知bug列表”。若是您找到的bug在列表里已经有了，那就没必要再报告了，可是若是您认为本身掌握的信息比列表中的丰富，那不管如何也要与程序员联系。您提供的信息可能会使他们更简单地修复bug。

本文中提到的都是一些指导方针，没有哪一条是必须恪守的准则。不一样的程序员会喜欢不一样形式的bug报告。若是程序附带了一套报告bug的准则，必定要读。若是它与本文中提到的规则相抵触，那么请以它为准。

若是您不是报告bug，而是寻求帮助，您应该说明您曾经到哪里找过答案，（例如：我看了第四章和第五章的第二节，但我找不到解决的办法。）这会使程序员了解用户喜欢到哪里去找答案，从而使程序员把帮助文档作得更容易使用。

“演示给我看”

报告bug的最好的方法之一是“演示”给程序员看。让程序员站在电脑前，运行他们的程序，指出程序的错误。让他们看着您启动电脑、运行程序、如何进行操做以及程序对您的输入有何反应。

他们对本身写的软件了如指掌，他们知道哪些地方不会出问题，而哪些地方最可能出问题。他们本能地知道应该注意什么。在程序真的出错以前，他们可能已经注意到某些地方不对劲，这些都会给他们一些线索。他们会观察程序测试中的每个细节，而且选出他们认为有用的信息。

这些可能还不够。也许他们以为还须要更多的信息，会请您重复刚才的操做。他们可能在这期间须要与您交流一下，以便在他们须要的时候让bug从新出现。他们可能会改变一些操做，看看这个错误的产生是个别问题仍是相关的一类问题。若是您不走运，他们可能须要坐下来，拿出一堆开发工具，花上几个小时研究。可是最重要的是在程序出错的时候让程序员在电脑旁。一旦他们看到了问题，他们一般会找到缘由并开始试着修改。

“告诉我该怎么作”

现在是网络时代，是信息交流的时代。我能够点一下鼠标把本身的程序送到俄罗斯的某个朋友那里，固然他也能够用一样简单的方法给我一些建议。可是若是个人程序出了什么问题，我不可能在他旁边。“演示”是很好的办法，可是经常作不到。

若是您必须报告bug，而此时程序员又不在您身边，那么您就要想办法让bug重如今他们面前。当他们亲眼看到错误时，就可以进行处理了。

确切地告诉程序员您作了些什么。若是是一个图形界面程序，告诉他们您按了哪一个按钮，依照什么顺序按的。若是是一个命令行程序，精确的告诉他们您键入了什么命令。您应该尽量详细地提供您所键入的命令和程序的反应。

把您能想到的全部的输入方式都告诉程序员，若是程序要读取一个文件，您可能须要发一个文件的拷贝给他们。若是程序须要经过网络与另外一台电脑通信，您或许不能把那台电脑复制过去，但至少能够说一下电脑的类型和安装了哪些软件（若是能够的话）。

“哪儿出错了？在我看来一切正常哦！”

若是您给了程序员一长串输入和指令，他们执行之后没有出现错误，那是由于您没有给他们足够的信息，可能错误不是在每台计算机上都出现，您的系统可能和他们的在某些地方不同。有时候程序的行为可能和您预想的不同，这也许是误会，可是您会认为程序出错了，程序员却认为这是对的。

一样也要描述发生了什么。精确的描述您看到了什么。告诉他们为何您以为本身所看到的是错误的，最好再告诉他们，您认为本身应该看到什么。若是您只是说：“程序出错了”，那您极可能漏掉了很是重要的信息。

若是您看到了错误消息，必定要仔细、准确的告诉程序员，它们很重要。在这种状况下，程序员只要修正错误，而不用去找错误。他们须要知道是什么出问题了，系统所报的错误消息正好帮助了他们。若是您没有更好的方法记住这些消息，就把它们写下来。只报告“程序出了一个错”是毫无心义的，除非您把错误消息一块报上来。

特殊状况下，若是有错误消息号，必定要把这些号码告诉程序员。不要觉得您看不出任何意义，它就没有意义。错误消息号包含了能被程序员读懂的各类信息，而且颇有可能包含重要的线索。给错误消息编号是由于用语言描述计算机错误经常使人费解。用这种方式告诉您错误的所在是一个最好的办法。

在这种情形下，程序员的排错工做会十分高效。他们不知道发生了什么，也不可能到现场去观察，因此他们一直在搜寻有价值的线索。错误消息、错误消息号以及一些莫名其妙的延迟，都是很重要的线索，就像办案时的指纹同样重要，保存好。

若是您使用UNIX系统，程序可能会产生一个内核输出（core dump）。内核输出是特别有用的线索来源，别扔了它们。另外一方面，大多数程序员不喜欢收到含有大量内核输出文件的EMAIL，因此在发邮件以前最好先问一下。还有一点要注意：内核输出文件记录了完整的程序状态，也就是说任何秘密（可能当时程序正在处理一些私人信息或秘密数据）均可
能包含在内核输出文件里。

出了问题以后，我作了……”

当一个错误或bug发生的时候，您可能会作许多事情。可是大多数人会使事情变的更糟。个人一个朋友在学校里误删了她全部的Word文件，在找人帮忙以前她重装了Word，又运行了一遍碎片整理程序，这些操做对于恢复文件是毫无益处的，由于这些操做搞乱了磁盘的文件区块。恐怕在这个世界上没有一种反删除软件能恢复她的文件了。若是她不作任何操做，或许还有一线但愿。

这种人仿佛一只被逼到墙角的鼬（黄鼠狼、紫貂一类的动物——译者注）：背靠墙壁，面对死亡的降临奋起反扑，疯狂攻击。他们认为作点什么总比什么都不作强。然而这些在处理计算机软件问题时并不适用。不要作鼬，作一只羚羊。当一只羚羊面对料想不到的状况或受到惊吓时，它会一动不动，是为了避免吸引任何注意，与此同时也在思考解决问题的最好办法（若是羚羊有一条技术支持热线，此时占线。）。而后，一旦它找到了最安全的行动方案，它便去作。

当程序出毛病的时候，马上中止正在作的任何操做。不要按任何按钮。仔细地看一下屏幕，注意那些不正常的地方，记住它或者写下来。而后慎重地点击 “肯定” 或“取消”，选择一个最安全的。学着养成一种条件反射——一旦电脑出了问题，先不要动。要想摆脱这个问题，关掉受影响的程序或者从新启动计算机都很差，一个解决问题的好办法是让问题再次产生。程序员们喜欢能够被重现的问题，快乐的程序员能够更快并且更有效率的修复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] 全部

最后，无论是谁，来这里回答问题都是凭一腔热忱，凭兴趣和心情，若是版面充斥让人没有兴趣回答的问题，我想，对你们都不是好消息。自力更生真的很重要，无论你水平如何遇到什么样的困难，能本身解决多少就解决多少，而后再来求助，说须要什么什么帮助，多作一些努力只有好处没有坏处，问一个好问题并不比问一个坏问题困难多少。

我我的的原则，一行之内的问题再也不回答了，好比‘有人懂JSP吗？如题’之类的问题我就
只看了。

本文来自：http://www.awflasher.com/blog/archives/200