不知道你们有没有遇到过,在技术群里有人问了一个问题,比如jar包为什么找不到了,或者直接截了一大串图。这样让想解决问题的人,往往感到很头疼,因为他们需要花大量的时间来定位,“他”想解决什么问题?
《提问的智慧》可以很好地解决这痛点。接下来给大家分享一下我的一个小小的体会。
1. 尝试在你准备提问的论坛的旧文章中搜索答案。
2. 尝试上网搜索以找到答案。
3. 尝试阅读手册以找到答案。
4. 尝试阅读常见问题文件(FAQ)以找到答案。
5. 尝试自己检查或试验以找到答案。
6. 向你身边的强者朋友打听以找到答案。
7. 如果你是程序开发者,请尝试阅读源代码以找到答案。
小心选择你要提问的场合。如果你做了下述的事情,你很可能被忽略掉或者被看作失败者:
* 在与主题不合的论坛上贴出你的问题。
* 在探讨进阶技术问题的论坛张贴非常初级的问题;反之亦然。
* 在太多的不同新闻群组上重复转贴同样的问题(cross-post)。
* 向既非熟人也没有义务解决你问题的人发送私人电邮。
蠢问题:救命啊!我的笔记本电脑不能正常显示了!
聪明问题:X.org 6.8.1 的鼠标光标会变形,某牌显卡 MV1005 芯片组。
更聪明问题:X.org 6.8.1 的鼠标光标,在某牌显卡 MV1005 芯片组环境下 - 会变形。
用清晰、正确、精准并语法正确的语句
精确的描述问题,并言之有物
清楚明确的表达你的问题以及需求
最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例(bug-demonstrating test case)。什么是最精简的测试用例?那是问题的缩影;一小个程序片段能刚好展示出程序的异常行为,而不包含其他令人分散注意力的内容。怎么制作最精简的测试用例?如果你知道哪一行或哪一段代码会造成异常的行为,复制下来并加入足够重现这个状况的代码(例如,足以让这段代码能被编译/直译/被应用程序处理)。如果你无法将问题缩减到一个特定区块,就复制一份代码并移除不影响产生问题行为的部分。总之,测试用例越小越好
避免用无意义的话结束提问,例如有人能帮我吗?或者这有答案吗?。
首先:如果你对问题的描述不是很好,这样问更是画蛇添足。
其次:由于这样问是画蛇添足,黑客们会很厌烦你 —— 而且通常会用逻辑上正确,但毫无意义的回答来表示他们的蔑视, 例如:没错,有人能帮你或者不,没答案。
一般来说,避免用 是或否、对或错、有或没有类型的问句,除非你想得到是或否类型的回答。
问题解决后,向所有帮助过你的人发个说明,让他们知道问题是怎样解决的,并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注,应该在那里贴一个说明比较恰当。
因篇幅问题不能全部显示,请点此查看更多更全内容