From 129c652908cc5628ddf30fa9abf105062d6ffe30 Mon Sep 17 00:00:00 2001 From: Jerry Lee Date: Fri, 2 Oct 2015 21:19:20 +0800 Subject: [PATCH] =?UTF-8?q?Bug=E4=B8=80=E8=AF=8D=E5=B7=B2=E7=BB=8F?= =?UTF-8?q?=E5=BE=88=E5=B8=B8=E7=94=A8=EF=BC=8C=E7=9B=B4=E6=8E=A5=E7=94=A8?= =?UTF-8?q?=E5=8D=95=E8=AF=8D=E6=9C=AC=E8=BA=AB=EF=BC=8C=E4=B8=8D=E7=BF=BB?= =?UTF-8?q?=E8=AF=91=E6=88=90=E3=80=8E=E8=87=AD=E8=99=AB=E3=80=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- how-to-ask-questions-the-smart-way/README.md | 28 ++++++++++---------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/how-to-ask-questions-the-smart-way/README.md b/how-to-ask-questions-the-smart-way/README.md index a8604d3..c5cb3ad 100644 --- a/how-to-ask-questions-the-smart-way/README.md +++ b/how-to-ask-questions-the-smart-way/README.md @@ -33,7 +33,7 @@ - [使用易于读取且标准的文件格式发送问题](#使用易于读取且标准的文件格式发送问题) - [描述问题应准确且有内容](#描述问题应准确且有内容) - [量不在多，精炼则灵](#量不在多精炼则灵) - - [别急于宣称找到臭虫](#别急于宣称找到臭虫) + - [别急于宣称找到`Bug`](#别急于宣称找到bug) - [低声下气代替不了做自己的家庭作业](#低声下气代替不了做自己的家庭作业) - [描述问题症状而不是猜测](#描述问题症状而不是猜测) - [按时间先后罗列问题症状](#按时间先后罗列问题症状) @@ -181,7 +181,7 @@ 为保护通信的渠道不被无关的东西淹没，黑客会除掉那些没有找对地方的问题，你不会想让这种事落到自己头上的。 因此，第一步是找对论坛。谷歌和其它搜索引擎还是你的朋友，可以用它们搜索你遇到困难的软硬件问题最相关的项目网站。那里通常都有项目的常见问题（`FAQ`）、邮件列表及文档的链接。 -如果你的努力（包括 **_阅读_** `FAQ`）都没有结果，这些邮件列表就是最后能取得帮助的地方。项目的网站也许还有报告臭虫的流程或链接，如果是这样，去看看。 +如果你的努力（包括 **_阅读_** `FAQ`）都没有结果，这些邮件列表就是最后能取得帮助的地方。项目的网站也许还有报告`Bug`的流程或链接，如果是这样，去看看。 向陌生的人或论坛发送邮件极有可能是在冒险。譬如，不要假设一个内容丰富的网页的作者想充当你的免费顾问，不要对你的问题是否会受到欢迎做太乐观的估计 —— 如果你不确定，向别处发或者压根别发。 @@ -250,7 +250,7 @@ 更一般地，想像一下在一个只显示主题的文档索引中查找。让你的主题更好地反映问题，可以使下一个搜索类似问题的人能够在文档中直接就找到答案的线索，而不用再次发贴提问。 -如果你想在回复中提问，确保改变主题以表明你是在问一个问题，一个主题像 『Re: 测试』 或者 『Re: 新臭虫』的消息不太可能引起足够的注意。同时，将回复中与新主题不甚相关的引用内容尽量删除。 +如果你想在回复中提问，确保改变主题以表明你是在问一个问题，一个主题像 『Re: 测试』 或者 『Re: 新`Bug`』的消息不太可能引起足够的注意。同时，将回复中与新主题不甚相关的引用内容尽量删除。 对于列表消息，不要直接点击回复按钮来开始一个全新的线索，这将限制你的观众。有些邮件阅读程序，比如`mutt`，允许用户按线索排序并通过折叠线索来隐藏消息，这样做的人永远看不到你发的消息。 @@ -324,29 +324,29 @@ 如果你认为是代码有问题，向黑客提供在可控环境下重现问题的方法尤其重要。当你这么做时，得到有用且及时回复的可能性将大大增加。 -西蒙 · 泰瑟姆（_Simon Tatham_）写过一篇 [如何有效报告臭虫](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html) 的文章，我强烈推荐各位阅读。 +西蒙 · 泰瑟姆（_Simon Tatham_）写过一篇 [如何有效报告`Bug`](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html) 的文章，我强烈推荐各位阅读。 ### 量不在多，精炼则灵 你应该写得精炼且有内容，简单地将一大堆代码或数据罗列在求助消息中达不到目的。如果你有一个很大且复杂的测试样例让程序崩溃，尝试将其裁剪得越小越好。 至少有三个理由支持这点。第一，让别人看到你在努力简化问题使你更有可能得到回复。 -第二，简化问题使你更有可能得到 **_有用的_** 回复。第三，在提纯臭虫报告的过程中，你可能自己就找到了解决办法或权宜之计。 +第二，简化问题使你更有可能得到 **_有用的_** 回复。第三，在提纯`Bug`报告的过程中，你可能自己就找到了解决办法或权宜之计。 -### 别急于宣称找到臭虫 +### 别急于宣称找到`Bug` -当你在一个软件中遇到问题，除非你 **_非常、非常_** 的有根据，不要动辄声称找到了臭虫。 +当你在一个软件中遇到问题，除非你 **_非常、非常_** 的有根据，不要动辄声称找到了`Bug`。 提示：除非你能提供解决问题的源代码补丁，或者对前一版本的回归测试表现出不正确的行为，否则你都多半不够完全确信。 -对于网页和文档也如此，如果你发现了文档的『臭虫』，你应该能提供相应位置的替代文本。 +对于网页和文档也如此，如果你发现了文档的『`Bug`』，你应该能提供相应位置的替代文本。 记住，还有许多其它用户并未经历你遇到的问题，否则你在阅读文档或搜索网页时就应该发现了（你在报怨前已经做了这些，[是吧](#提问前) ？）。 这也意味着很有可能是你弄错了而不是软件本身有问题。 -编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了臭虫，也就置疑了他们的能力，即使你是对的，也有可能会使其中的部分人感到不快。 -此外，在主题中嚷嚷『臭虫』也是特别不老练的。 +编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了`Bug`，也就置疑了他们的能力，即使你是对的，也有可能会使其中的部分人感到不快。 +此外，在主题中嚷嚷『`Bug`』也是特别不老练的。 -提问时，即使你私下非常确信已经发现一个真正的臭虫，最好写得像是 **_你_** 做错了什么。如果真的有臭虫，你会在回复中看到这点。 -这样做的话，如果真有虫子，维护者就会向你道歉，这总比你弄砸了然后欠别人一个道歉要强。 +提问时，即使你私下非常确信已经发现一个真正的`Bug`，最好写得像是 **_你_** 做错了什么。如果真的有`Bug`，你会在回复中看到这点。 +这样做的话，如果真有`Bug`，维护者就会向你道歉，这总比你弄砸了然后欠别人一个道歉要强。 ### 低声下气代替不了做自己的家庭作业 @@ -388,7 +388,7 @@ ### 描述目标而不是过程 -如果你想弄清楚如何做某事（而不是报告一个臭虫），在开头就描述你的目标，然后才陈述遇到问题的特定步骤。 +如果你想弄清楚如何做某事（而不是报告一个`Bug`），在开头就描述你的目标，然后才陈述遇到问题的特定步骤。 经常出现这种情况，寻求技术帮助的人在脑袋里有个更高层次的目标，他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身有问题，结果要费很大的劲才能通过。 @@ -471,7 +471,7 @@ 礼貌一点，使用『请』和『谢谢你的关注』或者『谢谢你的关照』，让别人明白你感谢他们无偿花时间帮助你。 坦率地讲，这一点没有语法正确、文字清晰、准确、有内容和避免使用专用格式重要（同时也不能替代它们）。 -黑客们一般宁可读有点唐突但技术鲜明的臭虫报告，而不是那种有礼但含糊的报告。（如果这点让你不解，记住我们是按问题能教我们什么来评价它的） +黑客们一般宁可读有点唐突但技术鲜明的`Bug`报告，而不是那种有礼但含糊的报告。（如果这点让你不解，记住我们是按问题能教我们什么来评价它的） 然尔，如果你已经谈清楚了技术问题，客气一点肯定会增加你得到有用回复的机会。