2017-12-29 提问的智慧
提问的心态
- 提问能力会越来越好
- 好的问题能让双方都有益
提问是一种沟通交流，有勇气问一些反常识的问题。
- 別用低聲下氣取代你真正該做的事
有些人明白他们不该粗鲁或傲慢的提问并要求得到答覆，但他们选择另一个极端-- 低声下气：“我知道我只是个可悲的新手，一个失败者，但...。”这既使人困扰，也没有用，尤其是伴随着与实际问题含糊不清的描述时更令人反感。
取而代之的是，尽可能清楚地描述背景条件和你的问题情况。这比低声下气更好地定位了你的位置。
- 如果还是搞不懂
看看这个问题是必须解决才能继续，还是可以放一放。必须解决的问题，请继续尝试。
- 如果得不到回答
如果你得不到回答，请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答案罢了。没有回应不代表你被忽视，虽然不可否认这种差别很难区分。
有点耐心，知道你问题答案的人可能生活在不同的时区，可能正在睡觉，也有可能你的问题一开始就没有组织好，再问问自己，如果换一种更容易理解的方式，你会怎么提问。
你可以通过其他管道获得帮助，这些管道通常更适合初学者的需要。
提问的对象
我们（在很大程度上）是自愿的，从繁忙的生活中抽出时间来解答疑惑，而且时常被提问淹没。所以我们无情的滤掉一些话题，特别是抛弃那些看起来像失败者的家伙，以便更高效的利用时间来回答赢家的问题。
如果你厌恶我们的态度，高高在上，或过于傲慢，不妨也设身处地想想。我们并没有要求你向我们屈服 -- 事实上，我们大多数人非常乐意与你平等地交流，只要你付出小小努力来满足基本要求，我们就会欢迎你加入我们的文化。但让我们帮助那些不愿意帮助自己的人是没有效率的。无知没有关系，但装白痴就是不行。
所以，你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你变得在行的特质 -- 机敏、有想法、善于观察、乐于主动参与解决问题。如果你做不到这些使你与众不同的事情，我们建议你花点钱找家商业公司签个技术支援服务合同，而不是要求黑客个人无偿地帮助你。
如果你决定向我们求助，当然你也不希望被视为失败者，更不愿成为失败者中的一员。能立刻得到快速并有效答案的最好方法，就是像赢家那样提问 -- 聪明、自信、有解决问题的思路，只是偶尔在特定的问题上需要获得一点帮助。
提問之前
image.png
尝试解决 RTFM 和 STFW 回应的问题
有一个古老而神圣的传统：如果你收到RTFM （Read The Fucking Manual）的回应，回答者认为你应该去读他妈的手册。当然，基本上他是对的，你应该去读一读。
RTFM 有一个年轻的亲戚。如果你收到STFW（Search The Fucking Web）的回应，回答者认为你应该到他妈的网上搜索过了。那人多半也是对的，去搜索一下吧。（更温和一点的说法是 Google是你的朋友！）
- 尝试在你准备提问的论坛的旧文章中搜寻答案。
- 尝试上网搜寻来找到答案。
- 尝试阅读手册来找到答案。
- 尝试阅读常见问题文件（FAQ）来找到答案。
- 尝试自己检查或试验来找到答案。向你身边的强者朋友打听来找到答案，如果你是程式开发者，请尝试阅读原始码来找到答案
image.png
当你提出问题的时候，请先表明你已经做了上述的努力；这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好，因为我们更乐于回答那些表现出能从答案中学习的人的问题。
问题类型
你想回答者提供什么帮助？
- 概念
- 行动方案
- 目标
image.png
漫无边际的提问近乎无休无止的时间黑洞。最有可能给你有用答案的人通常也正是最忙的人（他们忙是因为要亲自完成大部分工作）。这样的人对无节制的时间黑洞相当厌恶，所以他们也倾向于厌恶那些漫无边际的提问。
如果你明确表述需要回答者做什么（如提供指点、发送一段程式码、检查你的补丁、或是其他等等），就最有可能得到有用的答案。因为这会定出一个时间和精力的上限，便于回答者能集中精力来帮你。这么做很棒。
要理解专家们所处的世界，请把专业技能想像为充裕的资源，而回覆的时间则是稀缺的资源。你要求他们奉献的时间越少，你越有可能从真正专业而且很忙的专家那里得到解答。
所以，界定一下你的问题，使专家花在辨识你的问题和回答所需要付出的时间减到最少，这技巧对你有用答案相当有帮助。
描述问题
话不在多而在精
提供精确有内容的资讯。这并不是要求你简单的把成堆的出错程式码或者资料完全转录到你的提问中。如果你有庞大而复杂的测试样例能重现程式当掉的情境，尽量将它剪裁得越小越好。这样做的用处至少有三点。
- 表现出你为简化问题付出了努力，这可以使你得到回答的机会增加；
- 简化问题使你更有可能得到有用的答案；
- 在精炼你的bug报告的过程中，你很可能就自己找到了解决方法或权宜之计。
描述目标而不是过程
image.png
如果你想弄清楚如何做某事（而不是报告一个Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。
描述問題症狀而非猜測
image.png
你认为问题是怎样造成的并没什么帮助。 （如果你的推断如此有效，还用向别人求助吗？），因此要确信你原原本本告诉了他们问题的症状，而不是你的解释和理论；如果你认为陈述自己的猜测很重要，清楚地说明这只是你的猜测，并描述为什么它们不起作用。
针对诊断者而言，这并不是一种怀疑，而只是一种真实而有用的需求，以便让他们看到的是与你看到的原始证据尽可能一致的东西，而不是你的猜测与归纳的结论。所以，大方的展示给我们看吧！
按发生时间先后列出问题症状
问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。可以完整重现一次问题是如何发生的。
精确的描述问题并言之有物
仔细、清楚地描述你的问题的症状。
image.png
- 描述问题发生的环境（机器配置、作业系统、应用程式、以及相关的资讯），提供经销商的发行版和版本号（如：Fedora Core 4、Slackware 9.1等）。
- 描述在提问前你是怎样去研究和理解这个问题的。
- 描述在提问前为确定问题而采取的诊断步骤。
- 描述最近做过什么可能相关的硬体或软体变更。
- 尽可能的提供一个可以重制这个问题的既定环境的方法
- 尽量去揣测一个黑客会怎样反问你，在他提问的时候预先给他答案。
回顾
image.png
