手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆

转:程序员,你会问问题吗?

首页 > Misc >

其实看到这篇文章很久了,我一直忍着没有把它转过来。。在我眼里,这些什么《提问的智慧》,《提问的技巧》等等东西,就象小时候语文老师教的小说四要素一样:时间、地点、人物、情节,英文里称4w(when,where,who,what)。因此,在我看来,提问这玩意无非也就是我在什么时候,什么平台,当前的环境下,发生了什么问题。能够把这个事情说清楚的,即使你没有说,我刚才怎么处理怎么处理,还是没有搞定这个问题,我想别人在你能够描述这么清楚的情况下,也会帮忙解决你的问题的。

好吧。先转一个《提问的智慧》,我晶,居然还有版本修订:http://www.wapm.cn/smart-questions/smart-questions-zh.html,实在太长了,我懒得转了,就最后一句吧:

XML/HTML代码
  1. 伊夫林.米切尔(Evelyn Mitchell)贡献了一些愚蠢问题例子并启发了编写“如何更好地回答问题”这一节,米哈伊尔.罗门迪克(Mikhail Ramendik)贡献了一些特别有价值的建议和改进。  

 

然后再来两个小要点,因为我看现在QQ群里,如果别人提问不回答,这些人还会骂娘。有时候不知道到底是谁在提问,是谁需要回答:

XML/HTML代码
  1. 如果得不到回答  
  2.   
  3. 如果得不到回答,请不要认为我们不想帮你,有时只是因为被问到的小组成员的确不知道答案。没有回复不等于不被理睬,当然必须承认从外面很难看出两者的差别。   
  4. 一般而言,直接将问题再张贴一次不好,这会被视为毫无意义的骚扰。耐心一点,知道你问题答案的人可能生活在不同的时区,有可能正在睡觉,也有可能你的问题一开始就没有组织好。  
  5. 还有其它资源可以寻求帮助,通常是在一些面向新手的资源中。  
  6. 有许多在线与本地的用户组织,虽然它们自己不编写任何软件,但是对软件很热心。这些用户组通常因互助和帮助新手而形成。  
  7. 还有众多大小商业公司提供签约支持服务(红帽与 SpikeSource 是两家最出名的,还有许多其它的)。别因为要付点钱才有支持就感到沮丧!毕竟,如果你车子的汽缸垫烧了,你多半还得花钱找个修理店把它弄好。即使软件没花你一分钱,你总不能指望服务支持都是免费的。  
  8. 象 Linux 这样流行的软件,每个开发者至少有一万个以上的用户,一个人不可能应付这么多用户的服务要求。记住,即使你必须付费才能得到支持,也比你还得额外花钱买软件要少得多(而且对封闭源代码软件的服务支持与开源软件相比通常还要贵一点,也要差一点)。  
  9.   
  10. 如何更好地回答  
  11. 态度和善一点。问题带来的压力常使人显得无礼或愚蠢,其实并不是这样。  
  12. 对初犯者私下回复。 对那些坦诚犯错之人没有必要当众羞辱,一个真正的新手也许连怎么搜索或在哪找 FAQ 都不知道。  
  13. 如果你不确定,一定要说出来! 一个听起来权威的错误回复比没有还要糟,别因为听起来象个专家好玩就给别人乱指路。要谦虚和诚实,给提问者与同行都树个好榜样。
  14. 如果帮不了忙,别妨碍。 不要在具体步骤上开玩笑,那样也许会毁了用户的安装──有些可怜的呆瓜会把它当成真的指令。  
  15. 探索性的反问以引出更多的细节。 如果你做得好,提问者可以学到点东西──你也可以。试试将很差的问题转变成好问题,别忘了我们都曾是新手。  
  16. 尽管对那些懒虫报怨一声“读读该死的手册”(RTFM)是正当的,指出文档的位置(即使只是建议做个谷歌关键词搜索)会更好  
  17. 如果你决意回答,给出好的答案。 当别人正在用错误的工具或方法时别建议笨拙的权宜之计,应推荐更好的工具,重新组织问题。  
  18. 帮助你的社区从中学习。当回复一个好问题时,问问自己 “如何修改相关文件或 FAQ 文档以免再次解答同样的问题?”,接着再向文档维护者发一份补丁。  
  19. 如果你是在研究一番后才做出的回答,展现你的技巧而不是直接端出结果。毕竟“授人以鱼,不如授人以渔”。  

 

最后,转原文吧。。。

 

由于一直从事技术和平台产品方面的工作,我们部门经常会收到公司内外同事和同仁的问题邮件,有些好的问题能让你发现自己技术上的缺陷、产品的bug或提升的空间,去思考、回答和解决这样的问题真是一件让人愉悦,充满挑战和成就感的事情。但是非常遗憾的是,这样的好问题却是凤毛麟角。我经常会被一些莫名其妙的问题搞的啼笑皆非,比如:

  1. 程序运行过程中突然内存溢出,该如何解决?
  2. 如何配置JVM的虚拟机参数?
  3. 程序部署到Linux上后,页面出现中文乱码,是不是中间件的配置出现问题了?
  4. 集群节点不能自动复制,如何解决?

 

最可气是第四个问题,经过了解环境逐一排查,最后发现两个节点根本就ping不通嘛,这种“异常”在现场该是多么容易发现啊!

当然,类似的傻问题我年轻的时候也问过,谁会不犯错呢,真正让我认识到这一点的重要性,还是在工作中与国外程序员的邮件交流。在2005年期间,与国外程序员共同维护公司内部的一个平台级产品,邮件往来必不可少,慢慢的我发现国外的程序员提的问题或报的bug都非常有规律,每个问题或bug都有非常清晰的标题,正文是环境描述,已经采取了什么措施、结果,相关日志,Core dump,图片等等,一般读完邮件就能非常清楚的了解对方想要表达的意图和希望你能提供的帮助,而且你也知道该做什么,如何回复等等。久而久之,自己也不好意思再去写那些傻问题了。

那么作为技术人员,如何去问一个让双方都满意的好问题并最大程度的得到回复呢?这一点对提问者重要,对被问者同样重要,大好人生,谁也不愿意为一个烂问题浪费时间。

简单总结一下,如果你按照以下步骤进行,提出的问题一定会更靠谱一些,提出好的问题是你提升的第一步,其实这个过程在提问之前已经开始了:

  1. 遇到问题不要急着问别人,在时间允许的情况下看是否自己能够解决,一方面锻炼自己分析问题和解决问题的能力,另一方面,一旦问题解决了,问题就不是问题,而是你的经验和知识库。况且现在互联网有那么多的技术资料和各类问答网站,想碰到一个别人没碰到的问题,已经非常困难了,除非是内部产品。
  2. 如果做了努力依然不能解决,或者客观条件不允许你自己解决了,那么首先要选择提问对象,不管是社区还是公司同事,确保他是你所知道的最佳解决人选。
  3. 你需要一个好的标题,用清晰的短句描述你遇到的问题
  4. 至关重要的正文

    (1)用清晰的语言描述你遇到的问题  (2)提供软件环境,包括操作系统、数据库等相关软件及其版本号  (3)问题是否可以重现,采用什么方式重现  (4)采用了什么措施解决问题,最终结果(可提供日志、程序、截图等描述)  (5)尽可能提供问题相关的可分析文件,包括日志、截图和Core dump等  (6)不要长篇大论,简明扼要,描述主要问题 
  5. 最后,不要忘了说请和谢谢,毕竟你需要别人帮助你解决问题,没人欠你什么。  

 

 ---EOF---

上面这段来自:http://www.cnblogs.com/chijianqiang/archive/2012/09/24/question.html




本站采用创作共享版权协议, 要求署名、非商业和保持一致. 本站欢迎任何非商业应用的转载, 但须注明出自"易栈网-膘叔", 保留原始链接, 此外还必须标注原文标题和链接.

Tags: 问题, 提问

« 上一篇 | 下一篇 »

发表评论

评论内容 (必填):