码友别走 2021-02-21 15:32 采纳率: 0%
浏览 5812

为什么很多问题没人回答?什么是好的提问和回答?

为什么很多问题没人回答?

为什么很多回答无人点赞?

有没有一套好问题和好回答的标准?

  • 写回答

3条回答 默认 最新

  • CSDN问答 2021-02-21 15:55
    关注

    什么是好的提问,每个人都有自己的见解,可谓仁者见仁智者见智。在编程领域,Eric S. Raymond和Rick Moen曾为此写过一篇极有见地的文章,叫做《提问的智慧》,值得我们每个人认真阅读,相信大家也都能从中找到自己想要的答案。

    原文很长,这里从中摘录一些观点,供大家参考:

     

    精确地描述问题并言之有物
    仔细、清楚地描述你的问题或 Bug 的症状。
    描述问题发生的环境(机器配置、操作系统、应用程序、以及相关的信息),提供经销商的发行版和版本号(如:Fedora Core 4、Slackware 9.1等)。
    描述在提问前你是怎样去研究和理解这个问题的。
    描述在提问前为确定问题而采取的诊断步骤。
    描述最近做过什么可能相关的硬件或软件变更。
    尽可能的提供一个可以重现这个问题的可控环境的方法。
    尽量去揣测回答者会怎样反问你,在你提问之前预先将回答者可能遇到的问题回答一遍。

     

    话不在多而在精
    你需要提供精确有内容的信息。这并不是要求你简单的把成堆的出错代码或者资料完全转录到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境,尽量将它剪裁得越小越好。

    这样做的用处至少有三点。 第一,表现出你为简化问题付出了努力,这可以使你得到回答的机会增加; 第二,简化问题使你更有可能得到有用的答案; 第三,在精炼你的 bug 报告的过程中,你很可能就自己找到了解决方法或权宜之计。

     

    低声下气不能代替你的功课
    有些人明白他们不该粗鲁或傲慢的提问并要求得到答复,但他们选择另一个极端 —— 低声下气:我知道我只是个可悲的新手,一个撸瑟,但...。这既使人困扰,也没有用,尤其是伴随着与实际问题含糊不清的描述时更令人反感。

     

    按发生时间先后列出问题症状
    问题发生前的一系列操作,往往就是对找出问题最有帮助的线索。因此,你的说明里应该包含你的操作步骤,以及机器和软件的反应,直到问题发生。在命令行处理的情况下,提供一段操作记录(例如运行脚本工具所生成的),并引用相关的若干行(如 20 行)记录会非常有帮助。

     

    描述目标而不是过程
    如果你想弄清楚如何做某事(而不是报告一个 Bug),在开头就描述你的目标,然后才陈述重现你所卡住的特定步骤。

    经常寻求技术帮助的人在心中有个更高层次的目标,而他们在自以为能达到目标的特定道路上被卡住了,然后跑来问该怎么走,但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。


    清楚明确的表达你的问题以及需求
    漫无边际的提问是近乎无休无止的时间黑洞。最有可能给你有用答案的人通常也正是最忙的人(他们忙是因为要亲自完成大部分工作)。这样的人对无节制的时间黑洞相当厌恶,所以他们也倾向于厌恶那些漫无边际的提问。

    如果你明确表述需要回答者做什么(如提供指点、发送一段代码、检查你的补丁、或是其他等等),就最有可能得到有用的答案。因为这会定出一个时间和精力的上限,便于回答者能集中精力来帮你。这么做很棒。

     

    去掉无意义的提问句
    避免用无意义的话结束提问,例如有人能帮我吗?或者这有答案吗?

    首先:如果你对问题的描述不是很好,这样问更是画蛇添足。

    其次:由于这样问是画蛇添足,人们会很厌烦你 —— 而且通常会用逻辑上正确,但毫无意义的回答来表示他们的蔑视, 例如:没错,有人能帮你或者不,没答案。

    一般来说,避免用 是或否、对或错、有或没有类型的问句,除非你想得到是或否类型的回答。

     

    即使你很急也不要在标题写紧急
    这是你的问题,不是我们的。宣称紧急极有可能事与愿违:大多数回答者会直接忽视无礼和自私地企图即时引起关注的问题。

     

    礼多人不怪,而且有时还很有帮助
    彬彬有礼,多用请和谢谢您的关注,或谢谢你的关照。让大家都知道你对他们花时间免费提供帮助心存感激。

    坦白说,这一点并没有比清晰、正确、精准并合法语法和避免使用专用格式重要(也不能取而代之)。人们一般宁可读有点唐突但技术上鲜明的 Bug 报告,而不是那种有礼但含糊的报告。(如果这点让你不解,记住我们是按问题能教给我们什么来评价问题的价值的)

    然而,如果你有一串的问题待解决,客气一点肯定会增加你得到有用回应的机会。

     

    记得“采纳”答案
    如果某个回答解决了你的问题,记得点击“采纳”。这既是对回答者的感谢,也是告诉他人,你的问题得到了解决。

     

    问题解决后,加个简短的补充说明
    问题解决后,向所有帮助过你的人发个说明,让他们知道问题是怎样解决的,并再一次向他们表示感谢。

     

    《提问的智慧》全文链接:https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md

     

    至于什么样的回答是好的回答?

    简单来说,逻辑清晰、有见地、有可操作性、能解决提问者疑惑的回答,都算是好回答吧。有机会再详细阐述一下:)

    补充一个不错的回答案例:

    https://ask.csdn.net/questions/7398665?answer=53345159&spm=1005.2026.3001.5703

    评论

报告相同问题?

悬赏问题

  • ¥15 数据库数据成问号了,前台查询正常,数据库查询是?号
  • ¥15 算法使用了tf-idf,用手肘图确定k值确定不了,第四轮廓系数又太小才有0.006088746097507285,如何解决?(相关搜索:数据处理)
  • ¥15 彩灯控制电路,会的加我QQ1482956179
  • ¥200 相机拍直接转存到电脑上 立拍立穿无线局域网传
  • ¥15 (关键词-电路设计)
  • ¥15 如何解决MIPS计算是否溢出
  • ¥15 vue中我代理了iframe,iframe却走的是路由,没有显示该显示的网站,这个该如何处理
  • ¥15 操作系统相关算法中while();的含义
  • ¥15 CNVcaller安装后无法找到文件
  • ¥15 visual studio2022中文乱码无法解决