「有大佬在吗？」
你是不是经常在群里碰到这样的提问者，或者难道你就是！由于我建了几个技术群，经常会碰到这样的同学，前面几次我会直接@对方，然后告诉他有问题直接问就好了，有人看到就会回答了，不然，谁会跳出来承认自己是大佬呢？
后来，我干脆就写了这样的一篇文章，供群里的同学参看，没想到，受到大家的强烈赞同，今天发出来，让更多的同学，尤其是新入行的同学学会更好的提问，这样，你的问题才会更有机会得到别人的回答。
提问的艺术
作为一个程序员，把代码写好是本分，但仅仅是写好代码是不够的，工作的过程中总免不了要与别人打交道。几乎隔一段时间，我就会发现有些人身上出现下面的这两个问题。第一个就是不知道怎么提问，第二个就是有工作对接的时候，有用的信息不实时收集，多次对同样的问题进行提问。
今天来说一说如何提问的话题。说到这里，有点同学肯定在想，扯什么扯，提问谁不会呢，十万个为什么从小就听，回答问题不一定会，提问谁还不会呢。
可现实真的不是这样的，其实关于如何提问，这个问题由来已久，而且很多人都对此有过总结，甚至有一本书就叫做《提问的艺术》。这里所说的提问当然不是平时生活中所说的“你吃了没有？”、“吃的什么？”这么简单的问题。指的是专业方面的问题，作为程序员来讲，那就是关于开发、部署等方面的问题了。
我先来举几个糟糕的提问的例子：
有的同学在群里提问，上来就是：
- 接口返回404错误，是什么原因？
- dubbo 服务启动不了，可能是什么原因呢？
- 昨天还好好的，今天突然数据库就连不上了，有没有人知道怎么回事？
先别笑，这可不是开玩笑，相信你肯定也碰到过类似的提问，碰到这种提问除了让人啼笑皆非外，就只能是忽略了，当做什么都没看见。没有质量的提问就相当于垃圾信息，就是噪音，谁会理会噪音呢，除了是你的上司、朋友，可能会劈头盖脸的教育一通，旁人基本上就忽略了。
这种情况多发生在刚刚入门的同学身上，但也不全是，有些工作了好几年的同学也好不到哪里去。问题都提不好，我也不认为代码能好到哪里去。
记得，有一次，微信一下子弹出了好几条消息，正好挡住了我正要操作的内容，本来就心生不爽，点进去发现是一个同学正在群里问问题，5、6条消息发出来，仍然看的人一头雾水，不知所云。
解决问题不求人
这不废话吗，提问当然是遇到问题了。尤其是做开发，从刚刚入门的那天起，几乎每天都会遇到各种各样的问题。但是，并不是所有的问题都要找你的同事、群友来问的。
遇到问题第一步：看 IDE 提示
拿开发来讲，碰到的问题就是编译问题、运行时问题、逻辑漏洞，当碰到问题的时候，IDE 一定会给出提示，大部分问题都会根据提示自然而然的解决，例如弱智的少加了一个分号、少加了 @Override 等
遇到问题第二步：看日志
查看错误日志，有一些错误日志可以很明显的给出解释，例如 NPE 等等
遇到问题第三步：找 Google
搜索引擎了解一下，这可是一个巨大的宝藏，尤其是在今天，你遇到的所有问题几乎都有其他的人遇到过，除非你是在做一个从来没有人碰过的领域。建议选择 Google ，百度搜索不太合适开发。
遇到问题第四步：提问
只有前面几步都试过了，还是没有头绪，才采取这一步，向同事或者群友提问。到了这一步，就涉及到了今天说到的提问的方法。
-
讲清楚问题的背景，包括环境配置、版本说明，例如操作系统版本、Java 版本等，有些问题可能会涉及到 IDE ，也要说清楚；
-
问题的相关错误信息，包括日志信息、结果输出信息；
-
你曾做过什么尝试，针对每种尝试的不同结果是怎么样的；
-
如果是比较复杂的情况，看看能不能抽象出一个简单的模型，将复杂的问题简单化，方便其他人可以简单的理解，可能会更快的得到别人的回答；
-
还有一点也很重要。可能一个问题会有好多人回答，其中的一个或者多个方法可能行之有效的，那么，你在解决这个问题之后，一定要给回答者反馈。例如如果是在群里，可以 @回答者，这个问题已解决，用的是什么什么方法。这样一来，回答者会因为帮人解决了问题而有一些优越感，其他人也会了解这个过程，以后如果遇到相同的问题，也就知道怎么解决了。而提问者，做一个总结，也会给人一个良好的印象。如果别人回答完，就没动静了，至少我下一次再碰到他提问，就不会回答了，对，就是这么小肚鸡肠。
举个例子，假设遇到了一个 jvm OOM 的问题，并且经过一系列的日志分析、搜索引擎的搜索之后，仍然没有解决。那么就开始到群里提问。提问的第一步可能是这样的：
各位好，我现在遇到了一个 jvm OOM 的问题。现在的系统环境是这样的：
JDK 版本为 1.8 ，服务器为 CentOS 7.0 64位，机器内存 8 G，8 核，使用的垃圾收集器为 CMS，设置的 JVM 参数为：
-Xmx2688M -Xms2688M -Xmn960M -XX:MaxPermSize=512M -XX:PermSize=512M -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses -XX:+CMSClassUnloadingEnabled -XX:+ParallelRefProcEnabled -XX:+CMSScavengeBeforeRemark -XX:ErrorFile=/app/jvmlog/hs_err_pid%p.log -XX:HeapDumpPath=/app/jvmlog -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintClassHistogramBeforeFullGC -XX:+PrintClassHistogramAfterFullGC -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:+PrintHeapAtGC -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.port=9009出现的现象是什么情况的，然后把相关的日志信息提供出来，如果有必须的话，要提供 dump 文件。
然后把你做过的尝试以及尝试之后的结果一一说出来。这很重要。
然后把你猜测可能的原因说出来，例如项目中有 CPU 密集型任务，或者最近增加了某某功能可能产生什么影响。
这样提问之后，其他同学才能根据你给出的信息了解一个大致的情况，这时候，热心的同学或者有类似经验的同学才会根据你所给出的信息进行进一步分析，这样才能一步步得出解决方案。
禁忌
1、 如果有问题，直接按照上面说的方法把你的问题发出来就好，不要上来说一些无关痛痒的话，比如：
Q : 有人能帮我解决一个问题吗？
A : 对不起，没有
Q : 有大佬在吗？
A :对不起，不在
这中情况不光在提问的时候适用，在其他场合下同样适用，比如找朋友出去赏花、赏月、赏大腰子，有事情直接说。不然除了浪费双方的时间外，没有任何好处。
2、不要预设前提，比如太相信自己的某些功能或配置一定没有错，相信我，大部分错误都是很愚蠢的。
壮士且慢，先给点个赞吧，总是被白嫖，身体吃不消！
我是风筝，公众号「古时的风筝」。一个兼具深度与广度的程序员鼓励师，一个本打算写诗却写起了代码的田园码农！你可选择现在就关注我，或者看看历史文章再关注也不迟。
转载：https://blog.csdn.net/huhigher/article/details/106396782