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

本章阅读提示[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也并不是万能的，但这毕竟是一个很好的尝试，这有助于帮助你独立去解决问题，即使你找不到，黑客们也喜欢看到曾经你努力过，这将使他们跟你合作去解决这个问题。

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