是否能得到有用的回答,往往取决于你所提问和追问的方式。
一次吃晚餐,和同事讨论在开发过程中遇到了问题,怎么有效的向牛牛请教问题,同事推荐了下github上的这篇文章。卷呗~
1、提问题之前要做的事
- 尝试在你准备提问的论坛的旧文章中搜索答案。
- 尝试上网搜索以找到答案。
- 尝试阅读手册以找到答案。
- 尝试阅读常见问题文件以找到答案。
- 尝试自己检查或试验以找到答案。
- 向你身边的强者朋友打听以找到答案。
- 如果说程序开发者,尝试阅读源代码以找到答案。
这有助于树立一个并不是不劳而获且浪费别人时间的提问者。
如果能一并表达在做了上述努力的过程中所学到的东西会更好,因为牛牛更乐于回答那些表现出能从答案中学习的人的问题。
草率的发问只能得到草率的回答,或者根本得不到任何答案。越是能表现出在寻求帮助前为你解决问题所付出的努力,你越有可能得到实质性的帮助!
2、有意义且描述明确的标题
好标题的范例 目标--差异
的描述。不要用喋喋不休的帮帮忙
、跪求
、急
(更别说救命啊!!!!
)这样让人反感的话。
-
目标
指出哪一个或者哪一组东西有问题
-
差异
描述与期望的行为不一致的地方。
蠢问题:救命啊!我的笔电不能正常显示了!
聪明问题:X.org 6.8.1 的鼠标游标会变形,某牌显卡 MV1005 芯片组。
更聪明问题:X.org 6.8.1 的鼠标游标,在某牌显卡 MV1005 芯片组环境下 - 会变形。
方便让牛牛一眼就能明白你的环境和你遇到的问题。
3、精确的描述问题
- 仔细、清楚地描述你的问题或Bug的症状。
- 描述问题发生的环境。
- 描述在提问前你是怎样去研究和理解这个问题的。
- 描述在提问前为确定问题而采取的诊断步骤。
- 描述最近做过什么可能相关硬件或软件变更。
- 尽可能提供一个可以重现这个问题的可控环境的方法。
3.1、话不在多而在精
有庞大而复杂的测试样例能重现程序挂掉的情境,尽量将它剪裁的越小越好。
- 表现出你为简化问题付出了努力,这可以使你得到回答的机会增加。
- 简化问题是你更有可能得到有用的答案。
- 精炼Bug报告的过程中,很可能就自己找到了解决方法或权宜之计。
3.2、描述问题症状而非猜测
属于下头提问方式了...你怀疑是啥问题咋不去自己看捏
蠢问题:
我在编译内核时接连遇到 SIG11 错误,我怀疑某条飞线搭在主板的走线上了,这种情况应该怎样检查最好?
聪明问题:
我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU(威盛 Apollo VP2 芯片组),
256MB Corsair PC133 SDRAM 内存,在编译内核时,从开机 20 分钟以后就频频产生 SIG11 错误,
但是在头 20 分钟内从没发生过相同的问题。重新启动也没有用,但是关机一晚上就又能工作 20 分钟。
所有内存都换过了,没有效果。相关部分的标准编译记录如下…。
3.3、描述目标而不是过程
在想弄清楚如何做什么事,在开头就描述你的目的,然后才陈述重现你所卡住的特定步骤。
蠢问题:
我怎样才能从某绘图程序的颜色选择器中取得十六进制的的 RGB 值?
聪明问题:
我正试着用替换一幅图片的色码(color table)成自己选定的色码,我现在知道的唯一方法是编辑每个色码区块(table slot),
但却无法从某绘图程序的颜色选择器取得十六进制的的 RGB 值。
3.4、清楚明确的表达你的问题和需求
问“我想更好的理解X,可否指点一下哪有好一点说明?”通常比问“你能解释一下 X 吗?”更好。如果你的代码不能运作,请别人看看哪里有问题,比要求别人替你改正要明智得多。
要求他人帮你调试有问题的代码,不提示一下应该从何入手。张贴几百行的代码,然后说一声:“它不能工作”会让你完全被忽略
只贴几十行代码,然后说一句:“在第七行以后,我期待它显示 x,但实际出现的是 y” 比较有可能让你得到回应。
3.5、去掉无意义的提问句
避免用无意义的话结束提问,如 是或否
、对或错
、有或没有
类型的问句。除非你想得到是或否类型的答案。
有人能帮我吗?---没错,有人能帮你。
这有答案吗?---不,没有答案。
3.6、礼多人不怪
彬彬有礼,多用请
和谢谢您的关注
,或谢谢你的关照
。让大家都知道你对他们花时间免费提供帮助心存感激。
如果你有一串的问题待解决,客气一点肯定会增加你得到有用回应的机会。
4、如何解读答案
4.1、RTFM和STFW
-
RTFM
RTFM (Read The Fucking Manual)
,回答者认为你应该去读他妈的手册。 -
STFW
STFW(Search The Fucking Web)
,回答者认为你应该到他妈的网上搜索。
这些答复意味着回答者认为
- 你需要的信息非常容易获得。
- 你自己去搜索这些信息比灌给你能让你学到更多。
4.2、如果还是搞不懂
先试着去搞懂他的回应。如果你真的需要对方解释,记得表现出你已经从中学到了点什么。
4.3、处理无理的回应
如果你觉得被冒犯了,试着平静地反应。有些牛牛们回答问题可能是直接了当,一针见血式的交流风格,这种风格更注重解决问题,而不是使人感觉舒服而却模模糊糊。
你想得到的是信息而不是消磨时光,这时最好不要把手放在键盘上以免冒险。
5、不该问的问题
几个经典蠢问题,以及牛牛心中所想的
我能在哪找到 X 程序或 X 资源?---就在我找到它的地方啊,白痴 -- 搜索引擎的那一头。天哪!难道还有人不会用 Google 吗?
我怎样用 X 做 Y?---如果你想解决的是 Y ,提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知,也对 Y 要解决的问题糊涂,还被特定形势禁锢了思维。最好忽略这种人,等他们把问题搞清楚了再说。
如何设定我的 shell 提示??---如果你有足够的智慧提这个问题,你也该有足够的智慧去RTFM,然后自己去找出来。
我可以用 xxx方法 将 yyy 去实现 zzz 效果吗?---试试看就知道了。如果你试过,你既知道了答案,就不用浪费我的时间了。
我的{程序/SQL 语句}不工作 ---你还有什么要补充的吗?/真糟糕,希望你能搞定。/这关我有什么屁事?
我的 Windows 电脑有问题,你能帮我吗? ---能啊,扔掉微软的垃圾,换个Linux开放源代码操作系统吧。
我在安装 Linux(或者 X )时有问题,你能帮我吗? ---不能,我只有亲自在你的电脑上动手才能找到毛病。
6、好问题和蠢问题
-
蠢问题:
我可以在哪儿找到关于 xxx 的资料?
伸手党白嫖呗。
-
聪明问题:
我用 Google 搜索过 "xxx",但是没找到有用的结果。谁知道上哪儿去找xxx的资料?
-
蠢问题:
我从 xxx 项目找来的源码没法编译。它怎么这么烂?
都是别人的问题呗。
-
聪明问题:
xxx 项目代码在 Nulix 6.2 版下无法编译通过。我读过了 FAQ,但里面没有提到跟 Nulix 有关的问题。这是我编译过程的记录,我有什么做的不对的地方吗?
7、如何更好的回答问题
- 态度和善一点
- 对初犯者私下回复
- 如果不确定,一定要说出来
- 如果帮不了忙,也别妨碍他
- 试探性的反问以引出更多的细节
- 如果你决定回答,就请给出好的答案
- 正面的回答问题
- 如果是在研究一番后才做出的回答,展现你的技巧而不是直接端出结果。毕竟授人以鱼不如授人以渔。
8、分享一个教科书级别的例子
是之前在Halo的作者仙总的博客上看见的
评论区