如何避免问渣问题？

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

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

避免问愚蠢的问题

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

比如

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的检查功能矫正一下，避免被老外吐槽。

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