yunfei-dev/How-To-Ask-Questions-The-Smart-Way
1
1
Fork 0
mirror of https://github.com/yunfei-dev/How-To-Ask-Questions-The-Smart-Way.git synced 2025-02-25 21:04:04 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #18 from Sunlcy/Fibird

Browse Source 
修改了某些用词使之更加符合简体中文的表达
This commit is contained in:
Ryan Wu 2017-04-25 20:25:14 -04:00 committed by GitHub
commit 7885e0753d
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
README-zh_CN.md
View File

@ -131,7 +131,7 @@ __本指南不提供此项目的实际支持服务！__
黑客会剔除掉那些搞错场合的问题，以保护他们沟通的渠道不被无关的东西淹没。你不会想让这种事发生在自己身上的。
因此，第一步是找到对的论坛。再说一次，Google 和其它搜索引擎还是你的朋友，用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题（FAQ）、邮件列表及相关说明文件的链接。如果你的努力（包括**_阅读_** FAQ）都没有结果，网站上也许还有报告 Bug（Bug-reporting）的流程或链接，如果是这样，连过去看看。
因此，第一步是找到对的论坛。再说一次，Google 和其它搜索引擎还是你的朋友，用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题（FAQ）、邮件列表及相关说明文件的链接。如果你的努力（包括**_阅读_** FAQ）都没有结果，网站上也许还有报告 Bug（Bug-reporting）的流程或链接，如果是这样，链过去看看。
向陌生的人或论坛发送邮件最可能是风险最大的事情。举例来说，别假设一个提供丰富内容的网页的作者会想充当你的免费顾问。不要对你的问题是否会受到欢迎做太乐观的估计 -- 如果你不确定，那就向别处发送，或者压根别发。
@ -188,18 +188,18 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
### 使用有意义且描述明确的标题
在邮件列表、新闻群组或论坛中，大约 50 字以内的标题是抓住资深专家注意力的好机会。别用喋喋不休的```帮帮忙```、```跪求```、```急```（更别说```救命啊！！！！```这样让人反感的话，用这种标题会被条件反射式地忽略）来浪费这个机会。不要妄想用你的痛苦程度来打动我们，而是在这点空间中使用极简单扼要的描述方式来提出问题。
在邮件列表、新闻群组或论坛中，大约 50 字以内的标题是抓住资深专家注意力的好机会。别用喋喋不休的```帮帮忙```、```跪求```、```急```（更别说```救命啊！！！！```这样让人反感的话，用这种标题会被条件反射式地忽略）来浪费这个机会。不要妄想用你的痛苦程度来打动我们，而应该是在这点空间中使用极简单扼要的描述方式来提出问题。
一个好标题范例是```目标 -- 差异```式的描述，许多技术支持组织就是这样做的。在```目标```部分指出是哪一个或哪一组东西有问题，在```差异```部分则描述与期望的行为不一致的地方。
> 蠢问题：救命啊！我的笔电不能正常显示了！
> 蠢问题：救命啊！我的笔记本电脑不能正常显示了！
> 聪明问题：X.org 6.8.1 的鼠标游标会变形，某牌显卡 MV1005 芯片组。
> 聪明问题：X.org 6.8.1 的鼠标光标会变形，某牌显卡 MV1005 芯片组。
> 更聪明问题：X.org 6.8.1 的鼠标游标，在某牌显卡 MV1005 芯片组环境下 - 会变形。
> 更聪明问题：X.org 6.8.1 的鼠标光标，在某牌显卡 MV1005 芯片组环境下 - 会变形。
编写```目标 -- 差异``` 式描述的过程有助于你组织对问题的细致思考。是什么被影响了？ 仅仅是鼠标游标或者还有其它图形？只在 X.org 的 X 版中出现？或只是出现在 6.8.1 版中？ 是针对某牌显卡芯片组？或者只是其中的 MV1005 型号？ 一个黑客只需瞄一眼就能够立即明白你的环境**_和_**你遇到的问题。
编写```目标 -- 差异``` 式描述的过程有助于你组织对问题的细致思考。是什么被影响了？ 仅仅是鼠标光标或者还有其它图形？只在 X.org 的 X 版中出现？或只是出现在 6.8.1 版中？ 是针对某牌显卡芯片组？或者只是其中的 MV1005 型号？ 一个黑客只需瞄一眼就能够立即明白你的环境**_和_**你遇到的问题。
总而言之，请想像一下你正在一个只显示标题的存档讨论串（Thread）索引中查寻。让你的标题更好地反映问题，可使下一个搜索类似问题的人能够关注这个讨论串，而不用再次提问相同的问题。
@ -373,9 +373,9 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
别要求他人帮你调试有问题的代码，不提示一下应该从何入手。张贴几百行的代码，然后说一声：```它不能工作```会让你完全被忽略。只贴几十行代码，然后说一句：```在第七行以后，我期待它显示 <x>，但实际出现的是 <y>```比较有可能让你得到回应。
最有效描述程序问题的方法是提供最精简的 Bug 展示测试示例（bug-demonstrating test case）。什么是最精简的测试示例？那是问题的缩影；一小个程序片段能**刚好**展示出程序的异常行为，而不包含其他令人分散注意力的内容。怎么制作最精简的测试示例？如果你知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码（例如，足以让这段代码能被编译/直译/被应用程序处理）。如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，测试示例越小越好（查看[话不在多而在精](#话不在多而在精)一节）。
最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例（bug-demonstrating test case）。什么是最精简的测试用例？那是问题的缩影；一小个程序片段能**刚好**展示出程序的异常行为，而不包含其他令人分散注意力的内容。怎么制作最精简的测试用例？如果你知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码（例如，足以让这段代码能被编译/直译/被应用程序处理）。如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，测试用例越小越好（查看[话不在多而在精](#话不在多而在精)一节）。
一般而言，要得到一段相当精简的测试示例并不太容易，但永远先尝试这样做的是种好习惯。这种方式可以帮助你了解如何自行解决这个问题 —- 而且即使你的尝试不成功，黑客们也会看到你在尝试取得答案的过程中付出了努力，这可以让他们更愿意与你合作。
一般而言，要得到一段相当精简的测试用例并不太容易，但永远先尝试这样做的是种好习惯。这种方式可以帮助你了解如何自行解决这个问题 —- 而且即使你的尝试不成功，黑客们也会看到你在尝试取得答案的过程中付出了努力，这可以让他们更愿意与你合作。
如果你只是想让别人帮忙审查（Review）一下代码，在信的开头就要说出来，并且一定要提到你认为哪一部分特别需要关注以及为什么。