作為一個程序員，把代碼寫好是本分，但僅僅是寫好代碼是不夠的，工作的過程中總免不了要與別人打交道。幾乎隔一段時間，我就會發現有些人身上出現下面的這兩個問題。第一個就是不知道怎么提問，第二個就是有工作對接的時候，有用的信息不實時收集，多次對同樣的問題進行提問。
今天來說一說如何提問的話題。說到這里，有點同學肯定在想，扯什么扯，提問誰不會呢，十萬個為什么從小就聽，回答問題不一定會，提問誰還不會呢。
可現實真的不是這樣的，其實關於如何提問，這個問題由來已久，而且很多人都對此有過總結，甚至有一本書就叫做《提問的藝術》。這里所說的提問當然不是平時生活中所說的“你吃了沒有？”、“吃的什么？”這么簡單的問題。指的是專業方面的問題，作為程序員來講，那就是關於開發、部署等方面的問題了。
我先來舉幾個糟糕的提問的例子：
有的同學在群里提問，上來就是：
1、接口返回404錯誤，是什么原因？
2、dubbo 服務啟動不了，可能是什么原因呢？
3、昨天還好好的，今天突然數據庫就連不上了，有沒有人知道怎么回事？
先別笑，這可不是開玩笑，相信你肯定也碰到過類似的提問，碰到這種提問除了讓人啼笑皆非外，就只能是忽略了，當做什么都沒看見。沒有質量的提問就相當於垃圾信息，就是噪音，誰會理會噪音呢，除了是你的上司、朋友，可能會劈頭蓋臉的教育一通，旁人基本上就忽略了。
這種情況多發生在剛剛入門的同學身上，但也不全是，有些工作了好幾年的同學也好不到哪里去。問題都提不好，我也不認為代碼能好到哪里去。
記得，有一次，微信一下子彈出了好幾條消息，正好擋住了我正要操作的內容，本來就心生不爽，點進去發現是一個同學正在群里問問題，5、6條消息發出來，仍然看的人一頭霧水，不知所雲。
這不廢話嗎，提問當然是遇到問題了。尤其是做開發，從剛剛入門的那天起，幾乎每天都會遇到各種各樣的問題。但是，並不是所有的問題都要找你的同事、群友來問的。
遇到問題第一步：看 IDE 提示
拿開發來講，碰到的問題就是編譯問題、運行時問題、邏輯漏洞，當碰到問題的時候，IDE 一定會給出提示，大部分問題都會根據提示自然而然的解決，例如弱智的少加了一個分號、少加了 @Override 等
遇到問題第二步：看日志
查看錯誤日志，有一些錯誤日志可以很明顯的給出解釋，例如 NPE 等等
遇到問題第三步：找 Google
搜索引擎了解一下，這可是一個巨大的寶藏，尤其是在今天，你遇到的所有問題幾乎都有其他的人遇到過，除非你是在做一個從來沒有人碰過的領域。建議選擇 Google ，百度搜索不太合適開發。
遇到問題第四步：提問
只有前面幾步都試過了，還是沒有頭緒，才采取這一步，向同事或者群友提問。到了這一步，就涉及到了今天說到的提問的方法。
1、講清楚問題的背景，包括環境配置、版本說明，例如操作系統版本、Java 版本等，有些問題可能會涉及到 IDE ，也要說清楚；
2、問題的相關錯誤信息，包括日志信息、結果輸出信息；
3、你曾做過什么嘗試，針對每種嘗試的不同結果是怎么樣的；
4、如果是比較復雜的情況，看看能不能抽象出一個簡單的模型，將復雜的問題簡單化，方便其他人可以簡單的理解，可能會更快的得到別人的回答；
5、還有一點也很重要。可能一個問題會有好多人回答，其中的一個或者多個方法可能行之有效的，那么，你在解決這個問題之后，一定要給回答者反饋。例如如果是在群里，可以@回答者，這個問題已解決，用的是什么什么方法。這樣一來，回答者會因為幫人解決了問題而有一些優越感，其他人也會了解這個過程，以后如果遇到相同的問題，也就知道怎么解決了。而提問者，做一個總結，也會給人一個良好的印象。如果別人回答完，就沒動靜了，至少我下一次再碰到他提問，就不會回答了，對，就是這么小肚雞腸。
舉個例子，假設遇到了一個 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、如果有問題，直接按照上面說的方法把你的問題發出來就好，不要上來說一些無關痛癢的話，比如：
有人能幫我解決一個問題嗎？ ==> 對不起，沒有
有大佬在嗎？ ==> 對不起，不在
這個問題不光在提問的時候適用，在其他場合下同樣適用，有事情說事情。不然除了浪費雙方的時間外，沒有任何好處。
2、不要預設前提，比如太相信自己的某些功能或配置一定沒有錯，相信我，大部分錯誤都是很愚蠢的。
最后，各位同學不妨到我的公眾號里互動一下 : 古時的風箏 ，進入公眾號可以加入交流群
