提问的智慧（学习笔记）

摘录自 https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way

先尝试google

精确的描述问题并言之有物

• 仔细、清楚地描述你的问题或bug的症状。
• 描述问题发生的环境（机器配置、作业系统、应用程式、以及相关的资讯），提供经销商的发行版和版本号（如：Fedora Core 4、Slackware 9.1等）。
• 描述在提问前你是怎样去研究和理解这个问题的。
• 描述在提问前为确定问题而采取的诊断步骤。
• 描述最近做过什么可能相关的硬体或软体变更。
• 尽可能的提供一个可以重制这个问题的既定环境的方法
• 尽量去揣测一个黑客会怎样反问你，在他提问的时候预先给他答案。

如果还是搞不懂

如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网路，身边的高手），先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。也就是先要自己去努力，努力后仍然有疑问再告诉大佬自己努力的过程以及遇到的问题。

好问题与蠢问题

• 蠢问题：
  我可以在哪儿找到关于 Foonly Flurbamatic 的资料？
  这种问法无非想得到 STFW 这样的回答。

• 聪明问题：
  我用Google 搜寻过 “Foonly Flurbamatic 2600”，但是没找到有用的结果。谁知道上哪儿去找对这种设备编写程式的资料？
  这个问题已经 STFW 过了，看起来他真的遇到了麻烦。

• 蠢问题
  我从 foo 项目找来的源码没法编译。它怎么这么烂？
  他觉得都是别人的错，这个傲慢自大的提问者

• 聪明问题
  foo 专案程式码在 Nulix 6.2 版下无法编译通过。我读过了 FAQ，但里面没有提到跟 Nulix 有关的问题。这是我编译过程的记录，我有什么做的不对的地方吗？
  提问者已经指明了环境，也读过了FAQ，还列出了错误，并且他没有把问题的责任推到别人头上，他的问题值得被关注。

• 蠢问题
  我的主机板有问题了，谁来帮我？
  某黑客对这类问题的回答通常是：好的，还要帮你拍拍背和换尿布吗？ ，然后按下删除键。

• 聪明问题
  我在 S2464 主机板上试过了 X 、 Y 和 Z ，但没什么作用，我又试了 A 、 B 和 C 。请注意当我尝试 C 时的奇怪现象。显然 florbish 正在 grommicking，但结果出人意料。通常在 Athlon MP 主机板上引起 grommicking 的原因是什么？有谁知道接下来我该做些什么测试才能找出问题？

如何更好地回答问题

态度和善一点。问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。

对初犯者私下回覆。对那些坦诚犯错之人没有必要当众羞辱，一个真正的新手也许连怎么搜寻或在哪找常见问题都不知道。

如果你不确定，一定要说出来！一个听起来权威的错误回覆比没有还要糟，别因为听起来像个专家很好玩，就给别人乱指路。要谦虚和诚实，给提问者与同行都树个好榜样。

如果帮不了忙，也别妨碍他。不要在实际步骤上开玩笑，那样也许会毁了使用者的配置 --有些可怜的呆瓜会把它当成真的指令。

试探性的反问以引出更多的细节。如果你做得好，提问者可以学到点东西 --你也可以。试试将蠢问题转变成好问题，别忘了我们都曾是新手。

尽管对那些懒虫抱怨一声 RTFM 是正当的，能指出文件的位置（即使只是建议个 Google 搜寻关键词）会更好。

如果你决定回答，就请给出好的答案。当别人正在用错误的工具或方法时别建议笨拙的权宜之计（workaround），应推荐更好的工具，重新界定问题。

正面的回答问题！如果这个提问者已经很深入的研究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果，回答 试试看 A 或是 B 或者 试试X 、 Y 、 Z 、 A 、 B 、 C 并附上一个连结一点用都没有。

帮助你的社群从问题中学习。当回覆一个好问题时，问问自己如何修改相关文件或常见问题文件以免再次解答同样的问题？ ，接着再向文件维护者发一份补丁。

如果你是在研究一番后才做出的回答，展现你的技巧而不是直接端出结果。毕竟授人以鱼不如授人以渔。