首先,需要知道

要想得到一个好答案,首先得有个好问题

黑客讨厌伸手党,提问之前务必确保你仔细思考过该问题
就像黑客那样提问 —— 聪明、自信、有解决问题的思路,只是偶尔在特定的问题上需要获得一点帮助

黑客其实对新人很友好
“只要你付出小小努力来满足基本要求,我们就会欢迎你加入我们的文化。”

提问前,请做到以下事情

  1. 尝试在你准备提问的论坛的旧文章中搜索答案。
  2. 尝试上网搜索以找到答案。
  3. 尝试阅读手册以找到答案。
  4. 尝试阅读常见问题文件(FAQ)以找到答案。
  5. 尝试自己检查或试验以找到答案。
  6. 向你身边的强者朋友打听以找到答案。
  7. 如果你是程序开发者,请尝试阅读源代码以找到答案。
  8. 别着急,放轻松、坐舒服一些,再重复上面的操作

如果还是不行,那就要考虑好怎么提问了

  1. 表明提问前做过上面那些努力(有助于说明上下文和表明具备学习能力)
    例如:我在 Google 中搜过 xxx 但没有找到什么有用的东西
  2. 不要问错了问题,如果问题基于错误的假设,答案也将没有意义(X-Y Problem)
  3. 不要自以为提问就能得到答案,提问/交流时切记放低姿态
  4. 提问时给回答者更小的负担
    例如 请问我关于XX的思路正确吗? 要好过 请提供XX的完整思路

提出问题时,请做到:

  1. 搞清楚提问的场合是否正确
    1. 不在与主题不合的论坛上贴出你的问题。(常见 Github 借楼提问)
    2. 不在探讨进阶技术问题的论坛张贴非常初级的问题;反之亦然。
    3. 不在太多的不同新闻群组上重复转贴同样的问题(cross-post)。
    4. 不向既非熟人也没有义务解决你问题的人发送私人电邮。
  2. 找到正确的论坛
    1. 论坛具有较高的知名度和活跃度
    2. 它最好与你想问的问题强相关(例如开源软件的 issue)
    3. 它最好在国外(相对质量更高,或者说发现高质量国内资源成本更高,所以说英语很重要)
  3. 别像机关枪似的一次"扫射"所有的帮助渠道,要一个一个地来。

下面提供几个常见用于搜索答案和提问的网站:

国外:

  1. Stack Exchange: 常见的技术网站,可以用于Google后的精细化搜索
  2. Super User: 问一些电脑通用问题,与编程无关
  3. Stack Overflow:问写程序相关的问题
  4. Server Fault:问服务器和网管相关的问题。

国内:

  1. SegmentFault:国内的 Stack Overflow
  2. 博客园:是一个博客平台,里面有些大牛博主

在什么时候应该联系开发者?

或许你会好奇,很多开源项目放出了开发者的联系方式,但是上面却叫你不要联系他们……

那么什么时候才应该联系他们呢?

除了要做到上述内容,它还基于两个前提:

  1. 你足够强,确定问的问题不是 “蠢问题”(或者说你的问题要比较高级)
  2. 你确定你的问题能够引发开发者新的思考(或者说能对项目产生帮助)

提问的标题

对于回答者而言,首先看到的就是你的问题标题
如果标题给回答者的感觉就不好,那么回答者回答你问题的可能也会大大降低

因此你需要做到:

  1. 控制标题长度,50字以内
  2. 不要在标题中表述情感(例如:帮帮忙、跪求、救命啊……
  3. 别动辄声称找到 Bug(会让开发者觉得你在质疑其能力)

给起好标题提供一个思路:使用 目标-差异 式的描述
在目标部分指出是哪一个或哪一组东西有问题
在差异部分则描述与期望的行为不一致的地方
重要的是,这样的标题能够引导你对问题更细致的思考

注重细节

在黑客看来,粗心的提问者通常也会粗心的写程序与思考

所以请注意:

  1. 单词拼写、标点符号和大小是否正确
  2. 除非你确信在此处使用 黑客俚语 很准确,否则不要使用
  3. 除非很熟,不然不要滥用表情符号(比如 emoji)
  4. 在非母语的论坛提问记得表明身份(比如 I'm chinese, not good at English)这样别人会允许你犯点小错
  5. 在不知道开发者母语的情况下,一律使用英文交流
  6. 注意排版与格式
    1. 如果内容排版混乱会降低别人的回答欲望
    2. 不要使用 word、excel,使用 markdown

准确描述

尽量去揣测一个黑客会怎样反问你,在你提问之前预先将黑客们可能遇到的问题回答一遍。

  • 仔细、清楚地描述你的问题或 Bug 的症状。
  • 描述问题发生的环境(机器配置、操作系统、应用程序、以及相关的信息)
  • 描述在提问前你是怎样去研究和理解这个问题的。
  • 描述在提问前为确定问题而采取的诊断步骤。
  • 描述最近做过什么可能相关的硬件或软件变更。
  • 尽可能提供可以复现的可控环境的方法(为减小开发者复现的负担,测试用例越小越好!
  • 要确信你原原本本告诉了他们问题的症状,而不是你的解释和理论

问题解决后

问题解决后,记得做这些事情:

  1. 感谢问题的回答者
  2. 在对话的结尾表明问题已被解决
  3. 修改问题的 标题/状态 为已解决(例如关闭 Github 中的 Issue)

解读答案

RTFM 和 STFW

RTFM: Read the fucking manual

STFW: Search the fucking web

表明其实答案显而易见,提问前功课做的不足
不要对此感到不快,对方已经对你的提问表示关注并回答了

如果还是不懂

别立刻要求对方解释。像你以前试着自己解决问题时那样(利用手册,FAQ,网络,身边的高手),先试着去搞懂他的回应。如果你真的需要对方解释,记得表现出你已经从中学到了点什么。

总而言之,无论如何,保持友善
即便是被无礼回应也应该先忍一时,此处发飙将让你丢失在此获得答案的机会

如果得不到回答

并不是你的问题没有被发现,或许只是看到问题的人也不知道答案

可以通过其他渠道获得帮助:比如 付费的咨询服务

Q.E.D.


此 生 无 悔 恋 真 白 ,来 世 愿 入 樱 花 庄 。