- 文章
- 提问的智慧
2009年10月9日
提问的智慧
评分: 4.2/5 (40 票)
Eric Steven Raymond 作品的缩写版
首先要理解的是，程序员实际上喜欢难题和关于它们的好问题，发人深省的问题。 如果我们不喜欢，我们就不会在这里
程序员以对简单问题表现出敌意或傲慢而闻名。有时看起来我们是对菜鸟和无知者的一种本能性的粗鲁。 但这并非完全正确。
准备好你的问题。仔细思考。草率的问题只会得到草率的答案，或者根本没有答案。
使用有意义的、具体的标题 标题是你吸引合格专家注意力的黄金机会。不要把它浪费在诸如“请帮帮我”之类的闲聊上。不要试图用你的痛苦程度来打动我们；而是用这个空间来写一个超级简洁的问题描述。
更一般地说，想象一下查看问题存档的索引，只显示主题行。让你的主题行充分反映你的问题，以便下一个搜索与你类似问题的家伙能够跟随该线程找到答案，而不是再次发布问题。
用清晰的、符合语法的、拼写正确的语言写作
清晰地表达你的问题非常重要。花额外的精力来润色你的语言。不一定要生硬或正式。但必须精确。
不要使用全部大写字母；这会被解读为喊叫，并且被认为是不礼貌的。
如果你像一个半文盲的笨蛋一样写作，你很可能会被忽略。所以不要使用即时通讯的快捷方式。
精确而翔实地描述你的问题
尽你所能预测回答者会提出的问题，并在你的求助请求中提前回答它们。
数量并不等于精确 你需要精确而翔实。简单地将大量的代码或数据转储到帮助请求中并不能达到这个目的。如果你有一个庞大而复杂的测试用例，它正在破坏程序，请尝试修剪它，并使其尽可能小。
这至少有三个原因很有用。一：投入精力简化问题更容易获得答案。二：简化问题更容易获得有用的答案。三：在改进错误报告的过程中，你可能会自己开发出修复或解决方法。
描述问题的症状，而不是你的猜测 告诉程序员你认为是什么导致了你的问题没有用。所以，确保你告诉他们出错的原始症状，而不是你的解释和理论。让他们进行解释和诊断。如果你觉得说明你的猜测很重要，请清楚地将其标记为猜测，并描述为什么该答案对你不起作用。
描述目标，而不是步骤
如果你试图找出如何做某事，请首先描述目标。然后才描述你被阻止的特定步骤。
通常，需要技术帮助的人脑海中有一个高层次的目标，并且卡在他们认为通往该目标的特定路径上。他们来寻求该步骤的帮助，但没有意识到该路径是错误的。克服这一点可能需要大量的努力。
明确你的问题 开放式问题往往被认为是开放式的时间消耗。最有可能给你有用答案的人也是最忙的人（仅仅因为他们承担了最多的工作）。这样的人对开放式的时间消耗过敏，因此他们往往对开放式问题过敏。
如果你明确希望回答者做什么（提供指针，发送代码，...），你更有可能得到有用的回应。这将集中他们的精力，并隐含地为回答者必须分配的帮助你的时间和精力设定上限。
如果你只是想要代码审查，请提前说明，并务必提及你认为哪些领域可能特别需要审查以及原因。
你的跟进不必冗长而复杂；一个简单的 “你好，这是一个失败的网络电缆！谢谢大家。 - 比尔” 会好过什么都没有。
事实上，除非该解决方案具有真正的技术深度，否则简短而简洁的总结比冗长的论文更好。说明什么操作解决了问题，但你不需要重播整个故障排除过程。
除了礼貌和提供信息之外，这种跟进还将帮助搜索邮件列表/新闻组/论坛档案的其他人准确地知道哪个解决方案帮助了你，从而也可能帮助他们。
最后，但并非最不重要的一点，这种跟进有助于所有协助者对问题感到满意的了结感。问题叙述最终陷入未解决的虚无是很令人沮丧的；程序员渴望看到它们得到解决。挠痒痒所带来的善意，下次你需要提出问题时会对你非常有帮助。
如果你无法获得答案 如果你无法获得答案，请不要因为我们觉得自己无法帮助你而感到难过。有时，被问及的群体的成员可能根本不知道答案。没有回应与被忽略不同，虽然诚然从外面很难发现差异。
一般来说，简单地重新发布你的问题是一个坏主意。这会被认为是毫无意义的烦人。要有耐心：有你的答案的人可能在不同的时区并且正在睡觉。或者可能是你的问题一开始就措辞不好。
温柔一点。 与问题相关的压力会使人们看起来粗鲁或愚蠢，即使他们不是。
离线回复初犯。 对于一个可能犯了诚实错误的人，没有必要公开羞辱。一个真正的新手可能不知道如何搜索档案或 FAQ 存储或发布的位置。
如果你不确定，就说出来！ 一个错误的但听起来权威的答案比没有答案更糟糕。不要因为听起来像个专家很有趣而把任何人引向错误的道路。谦虚而诚实；为提问者和你的同伴树立一个好榜样。
如果你不能帮忙，就不要妨碍。 不要拿可能破坏用户设置的程序开玩笑 - 可怜的傻瓜可能会将这些解释为说明。
提出探测性问题以引出更多细节。 如果你擅长这一点，提问者会学到一些东西 - 你也可能会。尝试将错误的问题变成一个好问题；记住我们都曾经是新手。
虽然当回复一个只是懒惰的傻瓜时，嘟囔 RTFM 有时是合理的，但指向文档（即使只是建议在谷歌上搜索一个关键词）更好。
如果你要回答问题，那就给出好的价值。 当有人使用错误的工具或方法时，不要建议使用笨拙的解决方法。建议好的工具。重新构建问题。
简介
在编程世界里，你从技术问题中获得的答案质量，很大程度上取决于你提问的方式，以及解决答案的难度。首先要理解的是，程序员实际上喜欢难题和关于它们的好问题，发人深省的问题。 如果我们不喜欢，我们就不会在这里
程序员以对简单问题表现出敌意或傲慢而闻名。有时看起来我们是对菜鸟和无知者的一种本能性的粗鲁。 但这并非完全正确。
提问之前
在提出问题 a 之前，请执行以下操作- 尝试通过搜索你计划发布的论坛的档案来找到答案。
- 尝试通过搜索网络来找到答案。
- 尝试通过阅读手册来找到答案。
- 尝试通过阅读 FAQ 来找到答案。
- 尝试通过检查或实验来找到答案。
- 尝试通过向熟练的朋友提问来找到答案。
准备好你的问题。仔细思考。草率的问题只会得到草率的答案，或者根本没有答案。
提问时
仔细选择你的论坛 选择提问的地点时要谨慎。如果出现以下情况，你很可能会被忽略- 将你的问题发布到与主题无关的论坛
- 将一个非常基本的问题发布到期望高级技术问题的论坛，反之亦然
使用有意义的、具体的标题 标题是你吸引合格专家注意力的黄金机会。不要把它浪费在诸如“请帮帮我”之类的闲聊上。不要试图用你的痛苦程度来打动我们；而是用这个空间来写一个超级简洁的问题描述。
更一般地说，想象一下查看问题存档的索引，只显示主题行。让你的主题行充分反映你的问题，以便下一个搜索与你类似问题的家伙能够跟随该线程找到答案，而不是再次发布问题。
用清晰的、符合语法的、拼写正确的语言写作
清晰地表达你的问题非常重要。花额外的精力来润色你的语言。不一定要生硬或正式。但必须精确。
不要使用全部大写字母；这会被解读为喊叫，并且被认为是不礼貌的。
如果你像一个半文盲的笨蛋一样写作，你很可能会被忽略。所以不要使用即时通讯的快捷方式。
精确而翔实地描述你的问题
- 仔细、清晰地描述你问题的症状。
- 描述问题发生的环境（机器、操作系统、应用程序等等）。
- 描述你在提出问题之前为理解该问题所做的研究。
- 描述你在提出问题之前为查明问题本身而采取的诊断步骤。
尽你所能预测回答者会提出的问题，并在你的求助请求中提前回答它们。
数量并不等于精确 你需要精确而翔实。简单地将大量的代码或数据转储到帮助请求中并不能达到这个目的。如果你有一个庞大而复杂的测试用例，它正在破坏程序，请尝试修剪它，并使其尽可能小。
这至少有三个原因很有用。一：投入精力简化问题更容易获得答案。二：简化问题更容易获得有用的答案。三：在改进错误报告的过程中，你可能会自己开发出修复或解决方法。
描述问题的症状，而不是你的猜测 告诉程序员你认为是什么导致了你的问题没有用。所以，确保你告诉他们出错的原始症状，而不是你的解释和理论。让他们进行解释和诊断。如果你觉得说明你的猜测很重要，请清楚地将其标记为猜测，并描述为什么该答案对你不起作用。
描述目标，而不是步骤
如果你试图找出如何做某事，请首先描述目标。然后才描述你被阻止的特定步骤。
通常，需要技术帮助的人脑海中有一个高层次的目标，并且卡在他们认为通往该目标的特定路径上。他们来寻求该步骤的帮助，但没有意识到该路径是错误的。克服这一点可能需要大量的努力。
明确你的问题 开放式问题往往被认为是开放式的时间消耗。最有可能给你有用答案的人也是最忙的人（仅仅因为他们承担了最多的工作）。这样的人对开放式的时间消耗过敏，因此他们往往对开放式问题过敏。
如果你明确希望回答者做什么（提供指针，发送代码，...），你更有可能得到有用的回应。这将集中他们的精力，并隐含地为回答者必须分配的帮助你的时间和精力设定上限。
提问有关代码时
不要让别人在不知道应该搜索什么样的问题的情况下调试你的错误代码。发布几百行代码，说“它不起作用”，会让你被忽略。发布十几行代码，说“在第 7 行之后，我原本期望看到 <x>，但却出现了 <y>”更有可能让你得到回应。如果你只是想要代码审查，请提前说明，并务必提及你认为哪些领域可能特别需要审查以及原因。
不要发布家庭作业问题
程序员很擅长发现家庭作业问题；我们大多数人都自己做过。这些问题是给你自己解决的，这样你才能从经验中学习。可以要求提示，但不能要求完整的解决方案。用关于解决方案的简短说明进行跟进
问题解决后，向所有帮助过你的人发送一份说明；让他们知道结果如何，并再次感谢他们的帮助你的跟进不必冗长而复杂；一个简单的 “你好，这是一个失败的网络电缆！谢谢大家。 - 比尔” 会好过什么都没有。
事实上，除非该解决方案具有真正的技术深度，否则简短而简洁的总结比冗长的论文更好。说明什么操作解决了问题，但你不需要重播整个故障排除过程。
除了礼貌和提供信息之外，这种跟进还将帮助搜索邮件列表/新闻组/论坛档案的其他人准确地知道哪个解决方案帮助了你，从而也可能帮助他们。
最后，但并非最不重要的一点，这种跟进有助于所有协助者对问题感到满意的了结感。问题叙述最终陷入未解决的虚无是很令人沮丧的；程序员渴望看到它们得到解决。挠痒痒所带来的善意，下次你需要提出问题时会对你非常有帮助。
如何理解答案
如果你不明白... 如果你不理解答案，请不要立即反弹要求澄清。使用你用来尝试回答原始问题的相同工具（手册、常见问题解答、网络、熟练的朋友）来理解答案。然后，如果你仍然需要请求澄清，请展示你所学到的东西。如果你无法获得答案 如果你无法获得答案，请不要因为我们觉得自己无法帮助你而感到难过。有时，被问及的群体的成员可能根本不知道答案。没有回应与被忽略不同，虽然诚然从外面很难发现差异。
一般来说，简单地重新发布你的问题是一个坏主意。这会被认为是毫无意义的烦人。要有耐心：有你的答案的人可能在不同的时区并且正在睡觉。或者可能是你的问题一开始就措辞不好。
如何以有用的方式回答问题
温柔一点。 与问题相关的压力会使人们看起来粗鲁或愚蠢，即使他们不是。
离线回复初犯。 对于一个可能犯了诚实错误的人，没有必要公开羞辱。一个真正的新手可能不知道如何搜索档案或 FAQ 存储或发布的位置。
如果你不确定，就说出来！ 一个错误的但听起来权威的答案比没有答案更糟糕。不要因为听起来像个专家很有趣而把任何人引向错误的道路。谦虚而诚实；为提问者和你的同伴树立一个好榜样。
如果你不能帮忙，就不要妨碍。 不要拿可能破坏用户设置的程序开玩笑 - 可怜的傻瓜可能会将这些解释为说明。
提出探测性问题以引出更多细节。 如果你擅长这一点，提问者会学到一些东西 - 你也可能会。尝试将错误的问题变成一个好问题；记住我们都曾经是新手。
虽然当回复一个只是懒惰的傻瓜时，嘟囔 RTFM 有时是合理的，但指向文档（即使只是建议在谷歌上搜索一个关键词）更好。
如果你要回答问题，那就给出好的价值。 当有人使用错误的工具或方法时，不要建议使用笨拙的解决方法。建议好的工具。重新构建问题。