提问的智慧

参考资料：提问的智慧

简介：
当你抛出一个技术问题，最终能否得到有用的回答，往往取决于你提问和追问的方式。
好问题可以提高我们的理解力，而且通常会暴露我们以前从没意识到或者思考过的问题。
对那些不愿思考、或者发问前不做他们该做的事的人的蔑视。那些人是时间杀手-他们只想索取，从不付出，消耗我们可用在更有趣的问题或更值得回答的人身上的时间。lusers和winner。
你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你变得在行的特质-机敏、有想法、善于观察、乐于主动参与解决问题。如果你做不到这些使你与众不同的事情，我们建议你花点时间找家商业公司签个技术支持服务合同。
如果你决定向我们求助，当然你也不希望被视为失败者，更不愿成为失败者中的一员。能立刻得到快速并有效答案的最好方法，就是像赢家那样提问--聪明、自信、有解决问题的思路，只是偶尔在特定问题上需要获得一点帮助。

在提问之前：
1.尝试在你准备提问的论坛的旧文章中搜索答案。
2.尝试上网搜索以得到答案。
3.尝试阅读手册以找到答案。
4.尝试阅读常见问题文件FAQ以找到答案。
5.尝试自己检查或试验以找到答案。
6.向你身边的强者朋友大厅以找到答案。
7.如果你是程序开发者，请尝试阅读源代码以找到答案。
Stack Overflow
使用有意义且描述明确的标题：一个好的标题范例 目标--差异

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

询问有关代码的问题时：
别要求他人帮你调试有问题的代码，不提示一下应该从何入手。张贴几百行的代码，然后说一声：它不能工作，会让你完全被忽略调。
只贴几十行代码，然后说一句：在第七行之后，我期待它显示<x>，但实际出现的是<y>比较有可能让你得到回应。
最有效描述程序问题的方法是提供最精简的Bug展示测试示例(bug-demonstrationg test case)。问题的缩影，一小个程序片段刚好展示出程序的异常行为，而不包含其他令人分散注意力的内容。

问题解决后，加个简短的补充说明：
最理想的方式向最初提问的话题，回复此消息，并在标题中包含 已修正，已解决。除非结论真的很有技术含量，否则简短可爱的小结比长篇大论更好。
思考一下怎样才能避免他人将来也遇到类似的问题，自问写一份文件或者加个常见问题（FAQ）会不会有帮助。如果是的话就将他们发给维护者。这种良好的后续行动实际上比传统的礼节更为重要，也是你如何透过善待他人而赢得声誉的方式，这是非常有价值的资产。

如何解读答案：
RFTW和STFW：
RFTW：Read The Fucking Manual 应该去读他妈的手册
STFW：Search The Fucking Web 应该到他妈的网上搜索