提问的智慧(3)

Posted on 2014-05-20

##使用易于读取且标准的文件格式发送问题

本章阅读提示[14]。

如果你将问题搞得复制难以阅读,它多半会被忽略,人们更愿读易懂的问题,所以:

    1. 使用纯文本而不是HTML格式;
    1. 发送邮件时如有附件,记得添加附件,同时记得检查附件内容是否能正常打开;
    1. 不要发送整段的文字,尝试将文字按主题分段;
    1. 发送数据时应该发送原始数据,让回复者看到的东西与你看到的一样;
    1. 很多邮件程序并不支持「Quoted-Printable」MIME编码,所以谨慎使用;
    1. 不要指望黑客们阅读封闭格式的文档,诸如微软公司的Word或Excel文件等。大多数黑客讨厌这种文件格式。即使他们能够处理,也很厌恶这么做;
    1. 如果你用Windows操作系统发送电子邮件,关闭微软的「引用」功能,以免在你的邮件中出现乱码;
    1. 切勿在在论坛勿滥用「表情符号」和「HTML」功能。使用一两个表情符号还可以,但使用过多的花哨彩色文本会使人认为你无法表达出你的意思。过滥地使用表情符号、色彩和字体会让看起来更傻逼;

如果你是使用图形界面的邮件客户端程序(如腾讯的Foxmail、微软公司的Outlook),注意它们的默认配置不一定满足以上的这些要求。不过大多数这类程序有「查看源码」的命令,可以用它来检查发件箱的消息,确保发送的是没有乱码的纯文本文件。

【本章注释】

[14]在本章中作者使用大量的计算机术语,我已尽量简化处理,同时,我认为以上的方法并不适合大多数的提问者,所以我在此总结一下适合普通用户的文件格式:

    1. Txt:直接粘贴,方便阅读;
    1. Pdf:文件规范,推荐使用;
    1. Doc:使用广泛,打开方便;
    1. Md:Markdown文本,未来趋势。

邮件送发建议使用网页端,邮件客户端推荐使用Outlook2013或Foxmail 7。

##准确简练地描述问题

问题的描述应该包含以下内容:

    1. 清晰的细节;
    1. 问题发生的环境(主机品牌、操作系统、应用程序,任何相关的),提供销售商的发行版和版本号(如:「Fedora Core 7」、「Slackware 9.1」等);
    1. 提问前做过的调查研究及对其的理解;
    1. 提问前为确定问题而采取的诊断步骤;
    1. 最近对计算机或软件配置的任何相关改变;
    1. 如果可能,提供在可控环境下重现问题的方法;

做大的努力预测黑客会提到的问题,并提前备好答案。

如果你认为是代码有问题,在可控环境下重现问题,并向黑客提供报告,这个的方法尤其重要。当你这么做时,你大有可能获得及时而有效的回复。

西蒙.泰瑟姆(Simon Tatham)曾写过一篇《如何有效报告bug》的文章,我强烈推荐各位阅读。

##话不在多,精炼最好

你应该精炼且简要地描述问题,简单地将堆砌代码或罗列数据是没有用的。如果你有一个体积庞大且复杂的测试样本,尝试将其裁剪,越小越好。

至少有三个理由支持以上这点。第一,让别人看到你在努力简化问题的过程,这会使你更有可能得到回复。第二,简化的问题更容易得到回复。第三,在简化的过程中,你有可能自己就找到了解决办法。

##别急于宣称找到bug

当你在一个软件中遇到问题时,除非你非常、非常的有根据,否则不要动辄声称找到了bug。提示:除非你能提供解决问题的源代码补丁,或者在前一版本的回归测试收集了足够的证据,否则你都不能够完全确信。对于网页和文档也如此,如果你声称发现了文档的「bug」,你应该提供可以替代的解决方案。

记住,还有许多用户并未经历你遇到的问题,否则你在阅读文档或搜索网页时早应该发现了(疑问:你在报怨前已经搜索过了,是吧?)。这也意味着很有可能是你弄错了,而不是软件本身有问题。

编写软件的人总会非常努力地优化修正这个软件。所以,如果你声称找到了bug,这是对他们能力的质疑,即使你是对的,也有可能会使某些人人感到不爽。此外,在标题中寻找「bug」也是相当不厚道的行为。

即使你私下已经非常确信发现一个真正的bug,你在提交问题时最好也写得像是你做错了什么。这样,如果是真有bug,你会在回复中获知,同时,维护者会向你道歉,这总比你无心破坏而欠下一个道歉要好。

##跪求也不能解决问题

有些人明白不应该采用粗鲁或傲慢的方式提问并要求得到答复,所以他们走了另一个极端,转而低声下气地哀求:「我知道我只是个可怜的菜鸟,一个loser,但……」。这种对实际问题含糊的描述特别令人反感,不但困扰,也没有用。

别用低级灵长类动物的老办法浪费时间,相反,尽可能清楚地描述背景情况和你的问题,这比摆出卑贱态度更有用,同时这也是对自己的重新定位。

有的论坛专门设置了新手提问区,如果你真的认为遇到了新手该遇到的问题,直接到那去提问就好,别再跪求了。

##描述症状,不做猜测

向黑客陈述你的猜测是没有用的(如果你的诊断理论真的那么有用,你还会向别人求助吗?)。所以,你只需要告诉他们问题的原始状态,而不是你的解释和理论,让他们来解释和诊断。如果你真的认为自己的猜测很重要,那么你就应该清楚地说明这只是你的猜测,并解释为什么不起作用。

愚蠢的提问:我在编译内核时接连遇到SIG11错误,怀疑主板上的某根电路丝断了,找到它们的最好办法是什么?

明智的提问:我组装的电脑(K6/233 CPU、FIC-PA2007 主板[威盛 Apollo VP2 芯片组]、Corsair PC133 SDRAM 256Mb 内存)最近在开机20分钟左右、做内核编译时频繁地报错,提示SIG11 ,但在头20分钟内从不出问题。重启动不会复位时钟,但会整夜关机。更换所有内存未解决问题,相关的典型编译会话日志附后。

鉴于不是每个人都不能做到明智的提问,所以这里有一句话可以给到你启示:「所有的诊断专家都来自密苏里州」。美国国务院的官方座右铭则是「让我看看」(Show me)[15],对回复者而言,这并不是质疑,而只是一种真实而有用的需求,以便让他们看到与你看到一样的原始证据,目睹尽可能一致的东西,而不是你的片面的猜测与总结。(所以)让我们看看(Show me)。

【本章注释】

[15]「让我看看」出自国会议员威勒德.D.范迪弗[Willard D. Vandiver]在1899年时的讲话:「我来自一个出产玉米、棉花、牛蒡和民主党人的国家,滔滔雄辩既不能说服我,也不会让我满意。我来自密苏里州,你必须让我看看。」大意是我不相信别人的描述,我只相信我眼前的事实。

##按时间顺序描述问题症状

解决问题最有效的线索就是问题之前发生的情况。所以,在问题描述汇中应准确地记录你、电脑和软件在崩溃前的情况。在命令行处理的情况下,对话日志(如运行脚本工具生成的)的记录会非常有帮助。

如果崩溃的程序有诊断选项,试着选择能在能生成排错日志的选项。记住,「多」不等于「好」。试着选取适当的排错级别,以便提供有用的信息。

如果你的问题记录很长(如超过四段),在开头简述问题,随后按时间先后描述详细过程也许更有用。这样黑客在阅读你的记录时就知道该注意哪些内容了。

##描述目标而不是过程

如果你想知道如何做某事(而不是报告一个bug),你需要在开头就表明你的目标,然后再陈述你遇到问题。

经常出现这种一种情况:寻求技术帮助的人在脑中里有个更高层次的目标,他们自以为按自己的路走能达成目的,但在中途却被卡住了,又跑来问该怎么走,他们从来没有意识到这条路本身有问题,所以他们往往更折腾才能达成目的

愚蠢的提问:我怎样才能让某图形程序的颜色拾取器取得十六进制的RGB值?

明智的提问:我正试着用自己选定数值的颜色替换一幅图片的色表,我现在知道的唯一方法是编辑每个表槽,但却无法让某图形程序的颜色拾取器取得十六进制的RGB值。

第二种提法是明智的,它会获得更合适的回答:建议采用更合适的工具来完成任务。

##不要请求私下回复

黑客们认为问题的解决过程应该公开、透明,这样就会有更多的人参与到此问题的解决,如果有知识渊博,经验更丰富的人发现了这个问题,他们就会留意到回答中不完整或不准确的地方,那么原来的回答就会被纠正修复。同时,这些人的能力和学识也会被其他同行看到而得到赏识。

而当你要求私下回复时,以上的纠正过程就会被中止,所以,不要请求私下回复,要让回复者来决定是否私下回复。实际上,如果他真的私下回复你了,通常是因为他认为问题太差或者太肤浅,自己给出的答案对其它人也毫无意义,那就发给你吧。

这条规则也有一个例外,如果你确定该提问可能会带来大量雷同的回复时,那么你可以主动表示:「请向我发电子邮件,我将为论坛统一归纳这些回复」。你这个举动是非常值得赞扬的,因为你将论坛从洪水般雷同的回复中解救出来。最后,最重要的一点,你必须言出必行。

##精准地提问

漫无边际的问题通常被视为时间黑洞,回答这些问题需要付出更多的时间和精力,只有最忙的人才会给你最有用答案,但这些人对于时间黑洞极其敏感,所以他们比较讨厌那些漫无边际的问题。

如果你明确指认了让回复者做的事(如指点方向、发送代码、检查补丁或其它),你更有可能得到有用的回复。(因为)这样可以让他们集中精力去解决问题,并间接地设定了他们为帮助你需要花费的时间和精力上限,这是很好的做法。

如果你想要向专家提问,你可以这样设想:你去到一个金库,可是你只有一点点的时间。专家就像金库,如果你想在尽可能短的时间来换取更多的价值,你就要向他们提出一个精准的问题。

所以,为了让专家能够用尽量少的时间来回答你的问题,你最好限定问题的范围。限定问题范围与简化问题是不一样的。举个例,「请问可否指点一下哪有好一点关于X的解释?」通常就要比「请解释一下X」来得明智。再譬如,如果你的代码运行不了,「请别人看看哪有问题」就比「叫他们帮你改正」更加明智。

##如何提问关于代码的问题

不要直接要求别人给你修正代码,而应该提问如何入手解决这个问题,如果你一上来就一段几百行的代码,说你这里有bug提示出错,你能帮我找出来吗?这样的请求只会被直接无视,而如果你精简代码,明确地描述问题:在第七行以后,本应该显示,但实际出现的是,如何处理?这样就大大提高问题被回答的几率。

最精确描述代码问题的方法是提供一个能展现问题的最小测试样本。什么是最小测试样本?它是可以集中展现问题,只需要能够刚好重现问题的代码即可。如何生成一个最小测试样本?如果你知道哪一行或哪一段代码会产生问题,将其复制并提供刚好够用的外围支撑代码以构成一个完整的样本(够用是指源码刚好能被编译器、解释器或任何处理它的程序所接受)。如果你不能将问题缩小到特定的段落,复制源代码并去除那些与问题无关的代码段。你能提供的最小测试样例本越小越好(参见《浓缩精华》这一章节 )。

用最小测试样本去测试bug也并不是万能的,但这毕竟是一个很好的尝试,这有助于帮助你独立去解决问题,即使你找不到,黑客们也喜欢看到曾经你努力过,这将使他们跟你合作去解决这个问题。

如果你只是想让别人帮忙审核一下代码,在最开头就要说出来,并且一定要提到你认为哪一部分特别需要关注以及为什么。