链接:
我该知道的
能立刻得到快速并有效答案的最好方法,就是像赢家那样提问 —— 聪明、自信、有解决问题的思路,只是偶尔在特定的问题上需要获得一点帮助。
绝不要自以为够格得到答案,你没有;你并没有。毕竟你没有为这种服务支付任何报酬。你将会是自己去挣到一个答案,靠提出有内涵的、有趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题,而不仅仅是被动地从他人处索取知识。
提问前你必须需要知道的事情
- 要知道,
Free
的正确翻译是自由
,而非免费
。 - 要知道,愿意回答问题的人,都是 可爱 的人。
- 要知道,向帮助你的人
付费
是一个高尚的行为。即使回答你的人不是为了钱。 - 要知道,
花钱买时间是一个常识
。如果你不能认同,要么你钱包穷,要么你思想穷。 - 要知道,给对方发工资的不是你或者你老板。
- 要知道,提问的时候你才是 孙子,帮助你的人是 大爷。
- 要知道,不回答你的问题对其他人没有任何损失。
- 要知道,
准确描述一件事情
是一项基本生存技能。要学会 《提问的智慧》 - 要知道,
搜索
是一项基本生存技能,学不会用 Google 的话,你可能真的不适合你所从事的行业。 - 要知道,
英文
是一项基本生存技能,不认识英文的话,你可能真的不适合你所从事的行业。
我应该怎么做?
提问前:
在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前,请先做到以下事情:
- 尝试在你准备提问的论坛的旧文章中搜索答案。
- 尝试上网搜索以找到答案。
Google 和其它搜索引擎
比如先用 Google 搜索你所遇到的各种错误信息(搜索 Google 论坛和网页),这样很可能直接就找到了能解决问题的文件或邮件列表线索。
即使没有结果,在邮件列表或新闻组寻求帮助时加上一句 我在 Google 中搜过下列句子但没有找到什么有用的东西
也是件好事,即使它只是表明了搜索引擎不能提供哪些帮助。这么做(加上搜索过的字串)也让遇到相似问题的其他人能被搜索引擎引导到你的提问来。
- 尝试阅读手册以找到答案。
- 尝试阅读常见问题文件(FAQ)以找到答案。
别着急,不要指望几秒钟的 Google 搜索就能解决一个复杂的问题。在向专家求助之前,再阅读一下常见问题文件(FAQ)、放轻松、坐得舒服一些,再花点时间思考一下这个问题。相信我们,他们能从你的提问看出你做了多少阅读与思考,如果你是有备而来,将更有可能得到解答。不要将所有问题一股脑拋出,只因你的第一次搜索没有找到答案(或者找到太多答案)。
- 尝试自己检查或试验以找到答案。
- 向你身边的强者朋友打听以找到答案。
- 如果你是程序开发者,请尝试阅读源代码以找到答案。
表明你愿意在找答案的过程中做点什么。谁能给点提示?
、我的这个例子里缺了什么?
以及我应该检查什么地方
比请把我需要的确切的过程贴出来
更容易得到答复。因为你表现出只要有人能指个正确方向,你就有完成它的能力和决心。
提问时:
向陌生的人或论坛发送邮件最可能是风险最大的事情。举例来说,别假设一个提供丰富内容的网页的作者会想充当你的免费顾问
一般来说,在仔细挑选的公共论坛中提问,会比在私有论坛中提同样的问题更容易得到有用的回答。有几个理由可以支持这点,一是看潜在的回复者有多少,二是看观众有多少。黑客较愿意回答那些能帮助到许多人的问题。
怎么说:
- 请问一个关于
什么
的问题。 - 我想要达到
什么样
效果,但是我这样做出现了什么样
的问题。 - 报错日志是
这样
的。(要学会
画关键字) - 我尝试过
什么
方法来解决。 - 我尝试搜索过了
什么
关键字,在里面找到了这些 URL
的回答,尝试了还是没有解决问题。 - 我用的是
什么
操作系统,版本号是多少。 - 我用的是
什么
软件,版本号是多少。 - 谢谢
在哪搜索:
- google搜索
- Stack Exchange 社区
如果你还是找不到任何对你的问题有用的内容,请把你的问题发在与它最相关的网站上。提问的时候请善用格式化工具,尤其注意为代码添加格式,并且添加相关的标签(特别是编程语言、操作系统或库/包的名称)。当有人要求你提供更多相关信息时,请编辑你的贴子来补充它们[译注:而不是发一个回帖或回答!]。如果你觉得一个答案对你有帮助,点击向上的箭头来为它投票;如果一个答案提供了问题的正确解决方案,点击投票按钮下方的对勾来将它标记为正解。
Stack Exchange 已经成长到超过一百个网站,以下是最常用的几个站:
- Super User 是问一些通用的电脑问题,如果你的问题跟代码或是写程序无关,只是一些网络连线之类的,请到这里。
- Stack Overflow 是问写程序有关的问题。
- Server Fault 是问服务器和网管相关的问题。
- 网站和IRC论坛
(IRC:因特网中继聊天论坛)
本地的用户群组(user group),或者你所用的 Linux 发行版本也许正在宣传他们的网页论坛或 IRC 频道,并提供新手帮助(在一些非英语国家,新手论坛很可能还是邮件列表),这些都是开始提问的好地方,特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。有广告赞助的 IRC 频道是公开欢迎提问的地方,通常可以即时得到回应。如果程序出的问题只发生在特定 Linux 发行版提供的版本(这很常见),最好先去该发行版的论坛或邮件列表中提问,再到程序本身的论坛或邮件列表提问。
通过论坛或 IRC 频道来提供用户支持服务有增长的趋势,电子邮件则大多为项目开发者间的交流而保留。所以最好先在论坛或 IRC 中寻求与该项目相关的协助。
在使用 IRC 的时候,首先最好不要发布很长的问题描述,有些人称之为频道洪水。最好通过一句话的问题描述来开始聊天。
- 如果你需要个人电脑、Unix 系统和网络如何运作的基础知识,参阅 Unix 系统和网络基本原理。
- 当你发布软件或补丁时,试着按软件发布实践操作。
一个好标题范例
是目标 —— 差异
式的描述,许多技术支持组织就是这样做的。在目标
部分指出是哪一个或哪一组东西有问题,在差异
部分则描述与期望的行为不一致的地方。
蠢问题:救命啊!我的笔记本电脑不能正常显示了!
聪明问题:X.org 6.8.1 的鼠标指针会变形,某牌显卡 MV1005 芯片组。
更聪明问题:X.org 6.8.1 的鼠标指针,在某牌显卡 MV1005 芯片组环境下 - 会变形。
编写目标 —— 差异
式描述的过程有助于你组织对问题的细致思考。是什么被影响了? 仅仅是鼠标指针或者还有其它图形?只在 X.org 的 X 版中出现?或只是出现在 6.8.1 版中? 是针对某牌显卡芯片组?或者只是其中的 MV1005 型号? 一个黑客只需瞄一眼就能够立即明白你的环境和你遇到的问题。
使用英语书写
繁忙的黑客一般会直接删除用他们看不懂的语言写的消息。在网络上英语是通用语言,用英语书写可以将你的问题在尚未被阅读就被直接删除的可能性降到最低。
如果英文是你的外语(Second language),提示潜在回复者你有潜在的语言困难是很好的: [译注:以下附上原文以供使用]
English is not my native language; please excuse typing errors.
- 英文不是我的母语,请原谅我的错字或语法。
If you speak $LANGUAGE, please email/PM me; I may need assistance translating my question.
- 如果你说某语言,请向我发电邮/私信;
- 我需要有人协助我翻译我的问题。
I am familiar with the technical terms, but some slang expressions and idioms are difficult for me.
- 我对技术名词很熟悉,但对于俗语或是特别用法不甚了解。
I've posted my question in $LANGUAGE and English. I'll be glad to translate responses, if you only use one or the other.
- 我把我的问题用某语言和英文写出来。
- 如果你只用其中的一种语言回答,我会乐意将回复翻译成为你使用的语言。
精确地描述问题并言之有物
- 仔细、清楚地描述你的问题或 Bug 的症状。
- 描述问题发生的环境(机器配置、操作系统、应用程序、以及相关的信息),提供经销商的发行版和版本号(如:
Fedora Core 4
、Slackware 9.1
等)。 - 描述在提问前你是怎样去研究和理解这个问题的。
- 描述在提问前为确定问题而采取的诊断步骤。
- 描述最近做过什么可能相关的硬件或软件变更。
- 尽可能地提供一个可以
重现这个问题的可控环境
的方法。
尽量去揣测一个黑客会怎样反问你,在你提问之前预先将黑客们可能提出的问题回答一遍。
永远不要指望黑客们阅读使用封闭格式编写的文档,像微软公司的 Word 或 Excel 文件等。
描述问题症状而非你的猜测
告诉黑客们你认为问题是怎样造成的并没什么帮助。(如果你的推断如此有效,还用向别人求助吗?),因此要确信你原原本本告诉了他们问题的症状,而不是你的解释和理论;让黑客们来推测和诊断。如果你认为陈述自己的猜测很重要,清楚地说明这只是你的猜测,并描述为什么它们不起作用。
蠢问题
我在编译内核时接连遇到 SIG11 错误, 我怀疑某条飞线搭在主板的走线上了,这种情况应该怎样检查最好?
聪明问题
我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU(威盛 Apollo VP2 芯片组), 256MB Corsair PC133 SDRAM 内存,在编译内核时,从开机 20 分钟以后就频频产生 SIG11 错误, 但是在头 20 分钟内从没发生过相同的问题。重新启动也没有用,但是关机一晚上就又能工作 20 分钟。 所有内存都换过了,没有效果。相关部分的标准编译记录如下…
按发生时间先后列出问题症状
问题发生前的一系列操作,往往就是对找出问题最有帮助的线索。因此,你的说明里应该包含你的操作步骤,以及机器和软件的反应,直到问题发生。在命令行处理的情况下,提供一段操作记录(例如运行脚本工具所生成的),并引用相关的若干行(如 20 行)记录会非常有帮助。
如果挂掉的程序有诊断选项(如 -v 的详述开关),试着选择这些能在记录中增加调试信息的选项。记住,多
不等于好
。试着选取适当的调试级别以便提供有用的信息而不是让读者淹没在垃圾中。
如果你的说明很长(如超过四个段落),在开头简述问题,接下来再按时间顺序详述会有所帮助。这样黑客们在读你的记录时就知道该注意哪些内容了。
描述目标而不是过程
如果你想弄清楚如何做某事(而不是报告一个 Bug),在开头就描述你的目标,然后才陈述重现你所卡住的特定步骤。
经常寻求技术帮助的人在心中有个更高层次的目标,而他们在自以为能达到目标的特定道路上被卡住了,然后跑来问该怎么走,但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。
蠢问题
我怎样才能从某绘图程序的颜色选择器中取得十六进制的 RGB 值?
聪明问题
我正试着用替换一幅图片的色码(color table)成自己选定的色码,我现在知道的唯一方法是编辑每个色码区块(table slot), 但却无法从某绘图程序的颜色选择器取得十六进制的 RGB 值。
第二种提问法比较聪明,你可能得到像是建议采用另一个更合适的工具
的回复。
清楚明确地表达你的问题以及需求
问我想更好地理解 X,可否指点一下哪有好一点说明?
通常比问你能解释一下 X 吗?
更好。如果你的代码不能运作,通常请别人看看哪里有问题,比要求别人替你改正要明智得多。
即使你很急也不要在标题写紧急
这是你的问题,不是我们的。宣称紧急
极有可能事与愿违:大多数黑客会直接删除无礼和自私地企图即时引起关注的问题。更严重的是,紧急
这个字(或是其他企图引起关注的标题)通常会被垃圾信过滤器过滤掉 —— 你希望能看到你问题的人可能永远也看不到。
礼多人不怪,而且有时还很有帮助
彬彬有礼,多用请
和谢谢您的关注
,或谢谢你的关照
。让大家都知道你对他们花时间免费提供帮助心存感激。
问题解决后,加个简短的补充说明
问题解决后,向所有帮助过你的人发个说明,让他们知道问题是怎样解决的,并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注,应该在那里贴一个说明比较恰当。
最理想的方式是向最初提问的话题回复此消息,并在标题中包含已修正
,已解决
或其它同等含义的明显标记。在人来人往的邮件列表里,一个看见讨论串问题 X
和问题 X - 已解决
的潜在回复者就明白不用再浪费时间了(除非他个人觉得问题 X
有趣),因此可以利用此时间去解决其它问题。
补充说明不必很长或是很深入;简单的一句你好,原来是网线出了问题!谢谢大家 – Bill
比什么也不说要来的好。事实上,除非结论真的很有技术含量,否则简短可爱的小结比长篇大论更好。说明问题是怎样解决的,但大可不必将解决问题的过程复述一遍。
思考一下怎样才能避免他人将来也遇到类似的问题,自问写一份文件或加个常见问题(FAQ)会不会有帮助。如果是的话就将它们发给维护者。
蠢问题
有一个古老而神圣的传统:如果你收到RTFM(Read The Fucking Manual)
的回应,回答者认为你应该去读他妈的手册。当然,基本上他是对的,你应该去读一读。
RTFM 有一个年轻的亲戚。如果你收到STFW(Search The Fucking Web)
的回应,回答者认为你应该到他妈的网上搜索。那人多半也是对的,去搜索一下吧。(更温和一点的说法是 Google 是你的朋友!)
问题:我能在哪找到 X 程序或 X 资源?
回答:就在我找到它的地方啊,白痴 —— 搜索引擎的那一头。天哪!难道还有人不会用 Google 吗?
问题:我怎样用 X 做 Y?
回答:如果你想解决的是 Y ,提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知,也对 Y 要解决的问题糊涂,还被特定形势禁锢了思维。最好忽略这种人,等他们把问题搞清楚了再说。
问题:如何设定我的 shell 提示??
回答:如果你有足够的智慧提这个问题,你也该有足够的智慧去 RTFM,然后自己去找出来。
问题:我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 文件转换为 TeX 格式吗?
回答:试试看就知道了。如果你试过,你就知道了答案,就不用浪费我的时间了。
问题:我的{程序/设定/SQL 语句}没有用
回答:这不算是问题吧,我对要我问你二十个问题才找得出你真正问题的问题没兴趣 —— 我有更有意思的事要做呢。在看到这类问题的时候,我的反应通常不外如下三种
- 你还有什么要补充的吗?
- 真糟糕,希望你能搞定。
- 这关我屁事?
问题:我的 Windows 电脑有问题,你能帮我吗?
回答:能啊,扔掉微软的垃圾,换个像 Linux 或 BSD 的开源操作系统吧。
注意:如果程序有官方版 Windows 或者与 Windows 有互动(如 Samba),你可以问与 Windows 相关的问题,只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶, 因为 Windows 一般来说实在太烂,这种说法通常都是对的。
问题:我的程序不会动了,我认为系统工具 X 有问题
回答:你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库文件有明显缺陷的人,更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据,当你这样声称时,你必须有清楚而详尽的缺陷说明文件作后盾。
问题:我在安装 Linux(或者 X )时有问题,你能帮我吗?
回答:不能,我只有亲自在你的电脑上动手才能找到毛病。还是去找你当地的 Linux 使用群组者寻求实际的指导吧(你能在这儿找到用户群组的清单)。
注意:如果安装问题与某 Linux 的发行版有关,在它的邮件列表、论坛或本地用户群组中提问也许是恰当的。此时,应描述问题的准确细节。在此之前,先用 Linux
和所有被怀疑的硬件作关键词仔细搜索。
问题:我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢?
回答:想要这样做,说明了你是个卑鄙小人;想找个黑客帮你,说明你是个白痴!
通常,用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址,而且他们打这些字的时候也正在读着。这些答复意味着回答者认为:
- 你需要的信息非常容易获得;
- 你自己去搜索这些信息比灌给你,能让你学到更多。
你不应该因此不爽;依照黑客的标准,他已经表示了对你一定程度的关注,而没有对你的要求视而不见。你应该对他祖母般的慈祥表示感谢。
如果你看不懂回应,别立刻要求对方解释。像你以前试着自己解决问题时那样(利用手册,FAQ,网络,身边的高手),先试着去搞懂他的回应。如果你真的需要对方解释,记得表现出你已经从中学到了点什么。
比方说,如果我回答你:看来似乎是 zentry 卡住了;你应该先清除它。
,然后,这是一个很糟的后续问题回应:zentry 是什么?
好的问法应该是这样:哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries,而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗?还是我看漏了什么?
学会什么时候贴图
直接发送代码,IM 自动转义表情,贴出来的问题全是表情。
学会什么时候要圈出重点
千万不要认为别人的频率和你是同步的,然后像这样扔出一张图一个表情就了事了。
在工作中, 你@
的人可能会多问一句什么情况。 但是在 IM 聊天群里面,就没有这么好运气了
如下很难吗?
@xxx,我这边访问不了 git 仓库。
环境是: 环境是什么。