《提问的智慧》——如何更高效的提问和解决问题

不知道你们有没有遇到过，在技术群里有人问了一个问题，比如jar包为什么找不到了，或者直接截了一大串图。这样让想解决问题的人，往往感到很头疼，因为他们需要花大量的时间来定位，“他”想解决什么问题？

《提问的智慧》可以很好地解决这痛点。接下来给大家分享一下我的一个小小的体会。

一，在提问之前

1. 尝试在你准备提问的论坛的旧文章中搜索答案。

2. 尝试上网搜索以找到答案。

3. 尝试阅读手册以找到答案。

4. 尝试阅读常见问题文件（FAQ）以找到答案。

5. 尝试自己检查或试验以找到答案。

6. 向你身边的强者朋友打听以找到答案。

7. 如果你是程序开发者，请尝试阅读源代码以找到答案。

准备好你的问题，再将问题仔细的思考过一遍，因为草率的发问只能得到草率的回答，或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助。

二，当你提问时

1. 慎选提问的论坛

小心选择你要提问的场合。如果你做了下述的事情，你很可能被忽略掉或者被看作失败者：

* 在与主题不合的论坛上贴出你的问题。

* 在探讨进阶技术问题的论坛张贴非常初级的问题；反之亦然。

* 在太多的不同新闻群组上重复转贴同样的问题（cross-post）。

* 向既非熟人也没有义务解决你问题的人发送私人电邮。

在国内的话，你可以选择思否，知乎，CSDN等网站

2. 使用有意义且描述明确的标题

蠢问题：救命啊！我的笔记本电脑不能正常显示了！

聪明问题：X.org 6.8.1 的鼠标光标会变形，某牌显卡 MV1005 芯片组。

更聪明问题：X.org 6.8.1 的鼠标光标，在某牌显卡 MV1005 芯片组环境下 - 会变形。

3. 使问题容易回复

用清晰、正确、精准并语法正确的语句

精确的描述问题，并言之有物

清楚明确的表达你的问题以及需求

三，询问有关代码的问题时

最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例（bug-demonstrating test case）。什么是最精简的测试用例？那是问题的缩影；一小个程序片段能刚好展示出程序的异常行为，而不包含其他令人分散注意力的内容。怎么制作最精简的测试用例？如果你知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码（例如，足以让这段代码能被编译/直译/被应用程序处理）。如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，测试用例越小越好

四，去掉无意义的提问句

避免用无意义的话结束提问，例如有人能帮我吗？或者这有答案吗？。

首先：如果你对问题的描述不是很好，这样问更是画蛇添足。

其次：由于这样问是画蛇添足，黑客们会很厌烦你 —— 而且通常会用逻辑上正确，但毫无意义的回答来表示他们的蔑视， 例如：没错，有人能帮你或者不，没答案。

一般来说，避免用 是或否、对或错、有或没有类型的问句，除非你想得到是或否类型的回答。

五，问题解决后，加个简短的补充说明

问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注，应该在那里贴一个说明比较恰当。

六，不该问的坏问题

 

注：《提问的智慧》文档地址

https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/master/README-zh_CN.md