如何避免问渣问题?

其实这个问题已经被无数的人列举过、讨论过、吐槽过。但似乎很多人,特别是初学者/职业的入门者总是在问渣问题,而且自我感觉良好。如果非得要在大学加一门课的话,我特别希望就是“如何避免问渣问题“。并且特别希望它成为必修课之一。

当然,有些人问问题其实并不是在问问题,而可能是在讽刺、挖坑(知乎里特别流行)或者秀逼格。我不是很擅长这些,所以本文不在这些领域班门弄斧。

避免问愚蠢的问题

在提问之前,思考下这个问题是不是非常的愚蠢。尽管所有人(包括我)在内都愚蠢过,并且每个人也并不是会通晓所有领域。但是问的问题过度弱智,只会使得潜在的回答者觉得浪费智商。

比如

spring的服务端口怎么配置?

常用工具的文档都是公开的,非常容易找到。在问之前只要在搜索引擎敲两下即可找到。也许你会说某个不存在的网站无法访问。但Baidu虽然不太好用,但也并非完全用不了。除此之外,还有Bing,Stack Overflow,知乎,微信公众号等可以随时查。有时问题的讨论比问题的答案还要精彩。值得去细细阅读,摘抄笔记。也许20年前互联网尚不发达,很难找到相关资料。但是在201X年,不计其数网站,众多的大V不遗余力的解决各种问题,并且分享在网上。一般性常见问题只要肯找,几乎不可能找不到的。

当然,如果一不小心“蠢问”了几次,被耻笑了,也不用灰心丧气。吸取经验,下次再在提问前做好功课,慢慢提升就好。怕的是一直不思进取,那么神仙也救不了。就算是在一个付费的机构,频繁地向付费的老师提蠢问题,最终也会得到敷衍的回答而已。

特别值得留意的是有一种特别情况。提问者自己的理解与其他人的理解差距太大,以至于自己感觉问题提出来会很蠢。但是提问者自己真的非常不明白。这时一定要将理解的矛盾点在问题突出出来。比如

好多人都说nodejs的性能非常高。但是据我所知nodejs是个单线程的东西。单线程的东西怎么会跑的比多线程的东西更快呢?

这样一下子就让其他人理解,提问者是不太懂的“并发“的模型相关的概念和一些最佳实践。这样的问题其实一点都不蠢。

但如果改成

单线程比多线程跑得还快?

估计就不会有人理。

避免问过于宽泛宏大的问题

我经常被问这种问题

分布式系统怎么样?
java和python哪个好?
3年经验能拿多少薪酬?

在我看来,这些问题与下面的问题差不多

四川菜好吃吗?(我TM怎么知道你喜不喜欢吃?四川菜那么多种,火锅、串串、烧白……)
买什么车好?(你预算多少啊?你到底喜欢轿车还是SUV啊?卡车算车吗?……)
出国好玩还是去海南好玩?(你能先给个“玩”的定义吗?没准广东某城市更好玩。)

提出这类问题,多半源自于思维的。也许你在买个东西时也会这么问,对方销售会玩命追问你,但这是有利益驱动的。但是到了求教回答的时候,这种问题只能引起无尽的沉默。没人知道提问者想干嘛?如果真的要比较准确的回答,就得通篇大论数小时才能说清楚。敢问哪位有这样的闲工夫?

过于宽泛的问题有一个特例,就是“弯弯绕问题”。

避免问弯弯绕的问题

很多人喜欢这样问题。

用人用过/熟悉XXXX吗?

如果有人回答”使用过/接触过“,才会继续问真正的问题。

我用XXXX,这样这样配置了,结果出了那样那样的结果。为什么呢?

这么做在我看来大可不必。都要问问题了,还要省敲字的功夫吗?如果第一个问题没人答,就不打算敲第二个,真正的问题吗?对此,我的建议是:如果你很确认这个群/论坛,没人懂你要问的,那就别问了;如果可能会有人懂,就直接上真问题。

此外,提问者也要为回答者着想一下。如果是这样

问: 用过/熟悉XXXX吗?
答: 我曾经用过
问: XXXX,这样这样配置了,结果出了那样那样的结果。为什么呢?
答: (不是很懂这么细节的地方,是说不会还是就不理了呢?思考中……)

这的确会搞的回答者小郁闷,然后“吸取教训”再也不理这种问题。如果回答者一上来就能判定自己可不可以回答,那么事情简单直接的多。

避免问需要长篇大论才能把提问点说清楚的问题

另一个极端。“你不是说我问蠢问题吗,我就把细节都说出来“。

我用编程框架A,版本B,在操作系统C的版本D上开发。
下面是我的三个源代码。源文件X描述了模型1,Y文件描述了模型2。还有一个Z文件是这俩的配置文件。
----
源文件X
源文件X
源文件X
-----
源文件Y
源文件Y
源文件Y
-----
源文件Z
源文件Z
源文件Z
-----
那么当我采用复现步骤a,b,c后,期望得到结果P;结果我看到了结果Q
请问为什么?

这样的结构其实挺好的,只不过不是在问问题,而是作为QE在向团队开发成员提Bug。

一般人看到这种到两三行的时候就已经吐了,更不要说回答。

其实在问问题之前,相信提问者自己都有一点点猜想。这样就可以简化问题。比如先把问题的关键点用1~2行文字写一下(相当于一个摘要),然后再提供必要的细节。

又或者把代码中的关键部分提取出来,写一个几行的小程序说明问题,忽略那些不必要的步骤。这样其他人更容易辨识出问题的所在。

也许为了解决一个问题回答者可能需要提问者补充更多的细节。但是这些细节是双方都觉得必要才提供出来的。一上来就扔出来吓人非常不人道。

什么样的问题是好问题

上面说了这么多不要问什么样的问题。那么什么样的问题是好问题呢?简单罗列一些。凡事没有绝对,大家看看就好:

  • 简洁的说明了问题的要点。用两三行文字描述即可。如果要提供很多细节,要点需要提到问题的最前面。
  • 给出问题的简单的上下文。比如业务场景,技术场景等。但不要说得太复杂。
  • 给出了问问题之前的一些准备工作。比如查了什么地方是怎样说的。必要的复现步骤大概有哪些。但是必要时才给出。
  • 语文要过关。提问的文字写完后,最好稍微自己看一下,去掉一些容易产生误解的错字(比如因为拼音打出来的同音词;是/否这种逻辑词是否写反了等)。如果你是用英文在Stack Overflow之类的地方提问,最好也要好好检查拼写语法,必要时用word的检查功能矫正一下,避免被老外吐槽。

总之一句话,将心比心。如果你问的问题,别人用来你问你自己,你愿意回答,那么就是个说得过去的好问题。如果觉得本文还有点参考价值,不妨在问下个问题之前检查一下,看看是不是回答的问题多了一些,内容丰富了一些。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏java一日一条

最令程序员沮丧的 10 件事

软件开发是一个伟大的工作——和任何其他工作一样,它也有它的缺点。下面的10件事就是大多数程序员关于编程所无法苟同的。

1023
来自专栏PPV课数据科学社区

爬虫需谨慎!!!那些你不知道的爬虫反爬虫套路

作者简介 崔广宇,携程酒店研发部开发经理,与去哪儿艺龙的反爬虫同事是好基友。携程技术中心“非著名”段子手。 本文来自携程技术中心(ID:ctriptech) 前...

3804
来自专栏大前端开发

从编程小白到全栈开发:先定一个小目标

经过我上一篇文章的介绍,你是不是感觉自己开始对程序猿这个群体感兴趣了,或已立志成为他们中的一员?

1054
来自专栏腾讯玄武实验室的专栏

架构设计与安全:代码未写,漏洞已出。

来自 MIG 玄武实验室总监、专家工程师于旸,就基架构和设计的安全,给大家进行了关于安全问题的成因分享。

3811
来自专栏BestSDK

4个核心要点揭开爬虫真面目,小心被反爬!

爬虫与反爬虫,是一个很不阳光的行业。   这里说的不阳光,有两个含义。   第一是,这个行业是隐藏在地下的,一般很少被曝光出来。很多公司对外都不会...

4635
来自专栏云计算D1net

安全专家谈SDN能否带来更好的IT安全性

软件定义网络(SDN)即将成为现实,而且SDN在IT安全领域也同样获得了牵引力。有些供应商认为它将会在安全领域带来一定程度的互操作性,而这正是目前安全领域所欠缺...

3506
来自专栏腾讯大讲堂的专栏

自由测试人 Jarod 的一天

上午10:05 五道口漫咖啡,Jarod摆弄着新淘来的Nexus5手机,时而饮一口桌上的焦糖拿铁,间或偷眼瞄一下邻桌的长腿妹子。 上午10:30 Alliso...

2455
来自专栏程序你好

软件开发中的10大不为人知的真相

902
来自专栏云计算D1net

“从恨到爱” 甲骨文与微软结盟对抗亚马逊

在过去数十年,Oracle与微软是软件行业当之无愧的两大巨头,同时也是数十年的竞争对手——从数据库到ERP,从营销策略到法律诉讼。2013年之前,两位巨头在...

2625
来自专栏阮一峰的网络日志

五个为什么(译文)

昨天晚上,我终于把 More Joel on Software 翻译完了。 谢天谢地,总算可以摆脱这本书了。 唯一的感觉就是特别倦怠......检查完译稿以后,...

28412

扫码关注云+社区

领取腾讯云代金券