共有回帖数 0 个
-
这是一篇翻译自国外的文章，原文是一位国外的大牛写的，个人觉得不错，稍微总结了一下。
为什么提问总是没有人回答，看完此文瞬间顿悟……
总结来说：
1、提问之前，应预先做好功课，别问应该自己解决的问题。
最好已经看完所有初级教学、尝试过翻帮助解决问题。
周全的思考，准备好你的问题，草率的发问只能得到草率的回答，或者根本得不到任何答案。
越表现出在寻求帮助前为解决问题付出的努力，你越能得到实质性的帮助。
例如：别问一些已经被反复问过，或者搜索一下，就能解决的简单问题。
常见的：安装包哪里下？中文界面怎么切换？为什么切割工具和最新版不一样？
2、标题应该准确提炼问题关键，谨慎选择标题前缀和用词，去除无意义的内容。
无意义标题，例如：“新手求助，救命啊、跪求、裸求、哭求、在线等”之类的。
差标题：救命啊！求高手帮个忙啊！我怎么找也找不到！在线等
好标题：[粒子] 如何使用 Python 脚本访问每粒子属性？
主题标题是抓住高手注意力的金钥匙，使用含义丰富，描述准确的标题。
最忌讳用喋喋不休的“帮帮忙”、“救命啊！！！！！”、“求助！！！！“这样让人反感的词语。
不要妄想用你的痛苦程度来打动我们，别用空格代替问题的描述，哪怕是极其简短的描述。
3、帖子内容应该精确描述问题，信息量大。
话不在多，你需要提供精确有效的信息。
这并不是要求你简单的把成吨的出错代码完全转储摘录到你的提问中。
如果你有条件，尽量把它剪裁得越小越好。
例如：
谨慎明确的描述症状。(报错的内容)
提供问题发生的环境(系统版本，插件版本)。
说明你在提问前是怎样去研究和理解这个问题的。
说明你在提问前采取了什么步骤去解决它。
罗列最近做过什么可能有影响的设置变更。
这样做的用处至少有三点。
第一，表现出你为简化问题付出了努力，这可以使你得到回答的机会增加；
第二，简化问题使你得到有用答案的机会增加；
第三，在提炼你的错误信息的过程中，也许你自己就能找出问题所在或作出更正。
4、感谢解答者。
谦逊绝没有害处，而且常帮大忙，彬彬有礼，多用“请”和“先谢了”。
让大家都知道你对他们花费时间义务提供帮助心存感激。
然而，如果你有很多问题无法解决，礼貌将会增加你得到有用答案的机会。
5、问题解决后，加个解决问题的简短说明。
问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的。
补充说明不必很长或是很深入；
简单的一句“原来是插件安装的时候文件夹嵌套了，谢谢大家”比什么也不说要强。
事实上，除非结论真的很有技术含量，否则简短可爱的小结比长篇学术论文更好。
说明问题是怎样解决的，但大可不必将解决问题的过程复述一遍。
除了表示礼貌和反馈信息以外，这种补充有助于他人在论坛中搜索对你有过帮助的完整解决方案，这可能对他们也很有用。
因此建议在问题解决后，说明一下问题解决的办法，为后来遇到同样问题的人创造方便。
有助于别人搜到后，自行解决。也让别人知道你是一个乐于分享自己经验的人，这也有利于下次提问。
这种补充有助于所有提供过帮助的人从中得到满足感。
这种感觉对于那些你向他们求助的人而言，是非常重要的。
问题久拖未决会让人灰心；好人有好报，满足他们的渴望，你会在下次贴出新问题时尝到甜头。
最后，不管是谁，来这里回答问题都是凭一腔热忱，凭兴趣和心情，如果版面充斥让人没有兴趣回答的问题，我想，对大家都不是好消息。自力更生真的很重要，不管你水平如何遇到什么样的困难，能自己解决多少就解决多少，然后再来求助，说需要什么什么帮助，多做一些努力只有好处没有坏处，问一个好问题并不比问一个坏问题困难多少。
如何有效地报告 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。
楼主 2016-09-24 09:30 回复
Copyright © 2010~2015 直线网 版权所有,All Rights Reserved.沪ICP备10039589号
意见反馈 |
关于直线 |
版权声明 |
会员须知
