[节选]提问的智慧
2015-11-20 10:25
176 查看
本文节选自中文版《提问的智慧》,原文链接
https://github.com/FredWe/How-To-Ask-Questions-The-Smart-Way/blob/master/README-zh_CN.md
尝试在你准备提问的论坛的旧文章中搜索答案。
尝试上网搜索以找到答案。
尝试阅读手册以找到答案。
尝试阅读常见问题文件(FAQ)以找到答案。
尝试自己检查或试验以找到答案。
向你身边的强者朋友打听以找到答案。
如果你是程序开发者,请尝试阅读源代码以找到答案
当你提出问题的时候,请先表明你已经做了上述的努力;这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好,因为我们更乐于回答那些表现出能从答案中学习的人的问题。
准备好你的问题,再将问题仔细的思考过一遍,因为草率的发问只能得到草率的回答,或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力,你越有可能得到实质性的帮助。
使用有意义且描述明确的标题
使问题容易回复
用清晰、正确、精准并语法正确的语句
使用易于读取且标准的文件格式发送问题
精确的描述问题并言之有物
话不在多而在精
别动辄声称找到Bug
可以低声下气,但还是要先做功课
描述问题症状而非猜测
按发生时间先后列出问题症状
描述目标而不是过程
别要求使用私人电邮回复
清楚明确的表达你的问题以及需求
别把自己家庭作业的问题贴上来
去掉无意义的提问句
即使你很急也不要在标题写
礼多人不怪,而且有时还很有帮助
问题解决后,加个简短的补充说明
问题解决后,向所有帮助过你的人发个说明,让他们知道问题是怎样解决的,并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注,应该在那里贴一个说明比较恰当。
问题带来的压力常使人显得无礼或愚蠢,其实并不是这样。
对初犯者私下回复。
对那些坦诚犯错之人没有必要当众羞辱,一个真正的新手也许连怎么搜索或在哪找常见问题都不知道。
如果你不确定,一定要说出来!
一个听起来权威的错误回复比没有还要糟,别因为听起来像个专家很好玩,就给别人乱指路。要谦虚和诚实,给提问者与同行都树个好榜样。
如果帮不了忙,也别妨碍他。
不要在实际步骤上开玩笑,那样也许会毁了使用者的设置 –有些可怜的呆瓜会把它当成真的指令。
试探性的反问以引出更多的细节。
如果你做得好,提问者可以学到点东西 –你也可以。试试将蠢问题转变成好问题,别忘了我们都曾是新手。
如果你决定回答,就请给出好的答案。
当别人正在用错误的工具或方法时别建议笨拙的权宜之计(wordaround),应推荐更好的工具,重新界定问题。
正面的回答问题!
如果这个提问者已经很深入的研究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果,回答
帮助你的社区从问题中学习。
当回复一个好问题时,问问自己
https://github.com/FredWe/How-To-Ask-Questions-The-Smart-Way/blob/master/README-zh_CN.md
在提问之前
在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前,请先做到以下事情:尝试在你准备提问的论坛的旧文章中搜索答案。
尝试上网搜索以找到答案。
尝试阅读手册以找到答案。
尝试阅读常见问题文件(FAQ)以找到答案。
尝试自己检查或试验以找到答案。
向你身边的强者朋友打听以找到答案。
如果你是程序开发者,请尝试阅读源代码以找到答案
当你提出问题的时候,请先表明你已经做了上述的努力;这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好,因为我们更乐于回答那些表现出能从答案中学习的人的问题。
准备好你的问题,再将问题仔细的思考过一遍,因为草率的发问只能得到草率的回答,或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力,你越有可能得到实质性的帮助。
当你提问时
你需要提供精确有内容的信息,不是要求你简单的把成堆的出错代码或者资料完全转录到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境,尽量将它剪裁得越小越好。尽量去揣测一个可能的回答者会怎样反问你,在他提问的时候预先给他答案。当你这么做时,你得到有效的回答的机会和速度都会大大的提升。使用有意义且描述明确的标题
使问题容易回复
用清晰、正确、精准并语法正确的语句
使用易于读取且标准的文件格式发送问题
精确的描述问题并言之有物
话不在多而在精
别动辄声称找到Bug
可以低声下气,但还是要先做功课
描述问题症状而非猜测
按发生时间先后列出问题症状
描述目标而不是过程
别要求使用私人电邮回复
清楚明确的表达你的问题以及需求
别把自己家庭作业的问题贴上来
去掉无意义的提问句
即使你很急也不要在标题写
紧急
礼多人不怪,而且有时还很有帮助
问题解决后,加个简短的补充说明
问题解决后,向所有帮助过你的人发个说明,让他们知道问题是怎样解决的,并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注,应该在那里贴一个说明比较恰当。
如何更好地回答问题
态度和善一点。问题带来的压力常使人显得无礼或愚蠢,其实并不是这样。
对初犯者私下回复。
对那些坦诚犯错之人没有必要当众羞辱,一个真正的新手也许连怎么搜索或在哪找常见问题都不知道。
如果你不确定,一定要说出来!
一个听起来权威的错误回复比没有还要糟,别因为听起来像个专家很好玩,就给别人乱指路。要谦虚和诚实,给提问者与同行都树个好榜样。
如果帮不了忙,也别妨碍他。
不要在实际步骤上开玩笑,那样也许会毁了使用者的设置 –有些可怜的呆瓜会把它当成真的指令。
试探性的反问以引出更多的细节。
如果你做得好,提问者可以学到点东西 –你也可以。试试将蠢问题转变成好问题,别忘了我们都曾是新手。
如果你决定回答,就请给出好的答案。
当别人正在用错误的工具或方法时别建议笨拙的权宜之计(wordaround),应推荐更好的工具,重新界定问题。
正面的回答问题!
如果这个提问者已经很深入的研究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果,回答
试试看 A 或是 B或者
试试X 、 Y 、 Z 、 A 、 B 、 C并附上一个链接一点用都没有。
帮助你的社区从问题中学习。
当回复一个好问题时,问问自己
如何修改相关文件或常见问题文件以免再次解答同样的问题?,接着再向文件维护者发一份补丁。
相关文章推荐
- 为 MySQL 增加 HTTP/REST 客户端:MySQL UDF 函数 mysql-udf-http 1.0 发布
- 跨机备份设置磁盘映射
- 个人Git使用记录
- git 教程 文件托管到github
- android以欺骗的方法使用隐藏API调用举例(国际化,多语言)
- 学习笔记之ArcgisEngine 开发 10.1程序运行在10.0平台上的兼容问题解决
- Linux2.6.19内核(一)编译
- Redhat修改本地yum源
- HTTP协议详解
- [AlwaysOn Availability Groups]排查:AG配置
- javascript基础之面向对象(上)
- linux 服务管理
- copy函数
- Android开发之Menu:OptionMenu(选项菜单)、ContextMenu(上下文菜单)、SubMenu(子菜单)
- nginx反向代理及高速缓存
- gawk基础
- Android开发之Menu:OptionMenu(选项菜单)、ContextMenu(上下文菜单)、SubMenu(子菜单)
- block在ARC和MRC中的区别
- 动态查找表 事物隔离级别 reader
- C-位移运算