前言
为什么要规范问题格式?
因为在实际的学习中,总会遇到许许多多的问题提问方式,有些提问方式会显得更加高效率,而有些提问会极大的延长回复问题的时间,因此制作一个 关于技术性问题的提问模板
,就会显得比较重要
如果不想看那么多,只想获得一个模板格式,点我
这样做对我有什么好处?
对于每个人来讲,更加规范更加优秀的提问会极大的促进问答两个人之间的沟通效率,因此如何高效而又有效的问答,则是每个人需要学会的一件事。规范了问答格式,会让大家更倾向于去解决你的问题
提问的智慧
这个标题最早来自于GitHub的一个开源仓库,由于其中内容介绍的十分中肯,因此也是受到了许多同行们的fork以及star,因此如果有时间可以去阅读一下他的文章,文章链接
对于其中的一些问题,我做了一部分的节选(该章节其余内容来源于其文章内容):
话不在多而在精
你需要提供精确有内容的信息。这并不是要求你简单的把成堆的出错代码或者资料完全转录到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境,尽量将它剪裁得越小越好。
这样做的用处至少有三点。 第一,表现出你为简化问题付出了努力,这可以使你得到回答的机会增加; 第二,简化问题使你更有可能得到有用的答案; 第三,在精炼你的 bug 报告的过程中,你很可能就自己找到了解决方法或权宜之计。
描述目标而不是过程
如果你想弄清楚如何做某事(而不是报告一个 Bug),在开头就描述你的目标,然后才陈述重现你所卡住的特定步骤。
经常寻求技术帮助的人在心中有个更高层次的目标,而他们在自以为能达到目标的特定道路上被卡住了,然后跑来问该怎么走,但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。
蠢问题
我怎样才能从某绘图程序的颜色选择器中取得十六进制的 RGB 值?
聪明问题
我正试着用替换一幅图片的色码(color table)成自己选定的色码,我现在知道的唯一方法是编辑每个色码区块(table slot), 但却无法从某绘图程序的颜色选择器取得十六进制的 RGB 值。
第二种提问法比较聪明,你可能得到像是建议采用另一个更合适的工具
的回复。
清楚明确的表达你的问题以及需求
漫无边际的提问是近乎无休无止的时间黑洞。最有可能给你有用答案的人通常也正是最忙的人(他们忙是因为要亲自完成大部分工作)。这样的人对无节制的时间黑洞相当厌恶,所以他们也倾向于厌恶那些漫无边际的提问。
如果你明确表述需要回答者做什么(如提供指点、发送一段代码、检查你的补丁、或是其他等等),就最有可能得到有用的答案。因为这会定出一个时间和精力的上限,便于回答者能集中精力来帮你。这么做很棒。
要理解专家们所处的世界,请把专业技能想像为充裕的资源,而回复的时间则是稀缺的资源。你要求他们奉献的时间越少,你越有可能从真正专业而且很忙的专家那里得到解答。
所以,界定一下你的问题,使专家花在辨识你的问题和回答所需要付出的时间减到最少,这技巧对你有用答案相当有帮助 —— 但这技巧通常和简化问题有所区别。因此,问我想更好地理解 X,可否指点一下哪有好一点说明?
通常比问你能解释一下 X 吗?
更好。如果你的代码不能运作,通常请别人看看哪里有问题,比要求别人替你改正要明智得多。
别把自己家庭作业的问题贴上来
黑客们很擅长分辨哪些问题是家庭作业式的问题;因为我们中的大多数都曾自己解决这类问题。同样,这些问题得由你来搞定,你会从中学到东西。你可以要求给点提示,但别要求得到完整的解决方案。
如果你怀疑自己碰到了一个家庭作业式的问题,但仍然无法解决,试试在用户群组,论坛或(最后一招)在项目的用户邮件列表或论坛中提问。尽管黑客们会看出来,但一些有经验的用户也许仍会给你一些提示。
问题解决后,加个简短的补充说明
问题解决后,向所有帮助过你的人发个说明,让他们知道问题是怎样解决的,并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注,应该在那里贴一个说明比较恰当。
最理想的方式是向最初提问的话题回复此消息,并在标题中包含已修正
,已解决
或其它同等含义的明显标记。在人来人往的邮件列表里,一个看见讨论串问题 X
和问题 X - 已解决
的潜在回复者就明白不用再浪费时间了(除非他个人觉得问题 X
的有趣),因此可以利用此时间去解决其它问题。
补充说明不必很长或是很深入;简单的一句你好,原来是网线出了问题!谢谢大家 – Bill
比什么也不说要来的好。事实上,除非结论真的很有技术含量,否则简短可爱的小结比长篇大论更好。说明问题是怎样解决的,但大可不必将解决问题的过程复述一遍。
对于有深度的问题,张贴调试记录的摘要是有帮助的。描述问题的最终状态,说明是什么解决了问题,在此之后才指明可以避免的盲点。避免盲点的部分应放在正确的解决方案和其它总结材料之后,而不要将此信息搞成侦探推理小说。列出那些帮助过你的名字,会让你交到更多朋友。
除了有礼貌和有内涵以外,这种类型的补充也有助于他人在邮件列表/新闻群组/论坛中搜索到真正解决你问题的方案,让他们也从中受益。
至少,这种补充有助于让每位参与协助的人因问题的解决而从中得到满足感。如果你自己不是技术专家或者黑客,那就相信我们,这种感觉对于那些你向他们求助的大师或者专家而言,是非常重要的。问题悬而未决会让人灰心;黑客们渴望看到问题被解决。好人有好报,满足他们的渴望,你会在下次提问时尝到甜头。
思考一下怎样才能避免他人将来也遇到类似的问题,自问写一份文件或加个常见问题(FAQ)会不会有帮助。如果是的话就将它们发给维护者。
在黑客中,这种良好的后继行动实际上比传统的礼节更为重要,也是你如何透过善待他人而赢得声誉的方式,这是非常有价值的资产。
那我应该使用什么方式进行提问?
由于每个问题都会对应不同的提问框架,但是对于一般的技术性问题来讲,你大抵可以使用以下此类框架:
使用框架前你需要明确:
- 我已经阅读完毕 如何高效友好的提出一个技术性问题,并保证自己会遵守里面的相关要求
- 在你提出这个问题之前,你已经去查证在论坛或者其他你可以搜索到的地方没有人提出了相关问题
- 如果本文并未有效的帮助你更好的精简你的语言,我应该去看看 提问的智慧
- 我接下来要上传的内容不包含个人敏感信息(在上传日志、代码截图之前,我已经有效的处理好我的个人敏感信息)
- 如果我的问题并没有遵循相关要求,但是我还是提出了这个问题,那么我的问题会被无条件关闭或者被管理者拒绝回答
框架内容
如有需要,请将下方内容复制粘贴到你需要的地方即可
此处内容采用协议 Public Domain
框架1
1 | # 在开始之前 |
框架2
1 | # 在开始之前 |
结尾
Reference
本文协议
This work is licensed under a Creative Commons Attribution 4.0 International License.