爲何你在羣裏提的技術問題沒人回答？

做爲一個程序員，把代碼寫好是本分，但僅僅是寫好代碼是不夠的，工做的過程當中總免不了要與別人打交道。幾乎隔一段時間，我就會發現有些人身上出現下面的這兩個問題。第一個就是不知道怎麼提問，第二個就是有工做對接的時候，有用的信息不實時收集，屢次對一樣的問題進行提問。

今天來講一說如何提問的話題。說到這裏，有點同窗確定在想，扯什麼扯，提問誰不會呢，十萬個爲何從小就聽，回答問題不必定會，提問誰還不會呢。

可現實真的不是這樣的，其實關於如何提問，這個問題由來已久，並且不少人都對此有過總結，甚至有一本書就叫作《提問的藝術》。這裏所說的提問固然不是平時生活中所說的「你吃了沒有？」、「吃的什麼？」這麼簡單的問題。指的是專業方面的問題，做爲程序員來說，那就是關於開發、部署等方面的問題了。

我先來舉幾個糟糕的提問的例子：

有的同窗在羣裏提問，上來就是：

一、接口返回404錯誤，是什麼緣由？
二、dubbo 服務啓動不了，多是什麼緣由呢？
三、昨天還好好的，今天忽然數據庫就連不上了，有沒有人知道怎麼回事？

先別笑，這可不是開玩笑，相信你確定也碰到過相似的提問，碰到這種提問除了讓人哭笑不得外，就只能是忽略了，當作什麼都沒看見。沒有質量的提問就至關於垃圾信息，就是噪音，誰會理會噪音呢，除了是你的上司、朋友，可能會劈頭蓋臉的教育一通，旁人基本上就忽略了。

這種狀況多發生在剛剛入門的同窗身上，但也不全是，有些工做了好幾年的同窗也好不到哪裏去。問題都提很差，我也不認爲代碼能好到哪裏去。

記得，有一次，微信一會兒彈出了好幾條消息，正好擋住了我正要操做的內容，原本就心生不爽，點進去發現是一個同窗正在羣裏問問題，五、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 密集型任務，或者最近增長了某某功能可能產生什麼影響。

這樣提問以後，其餘同窗才能根據你給出的信息瞭解一個大體的狀況，這時候，熱心的同窗或者有相似經驗的同窗纔會根據你所給出的信息進行進一步分析，這樣才能一步步得出解決方案。

禁忌

一、若是有問題，直接按照上面說的方法把你的問題發出來就好，不要上來講一些無關痛癢的話，好比：

有人能幫我解決一個問題嗎？ ==> 對不起，沒有

有大佬在嗎？ ==> 對不起，不在

這個問題不光在提問的時候適用，在其餘場合下一樣適用，有事情說事情。否則除了浪費雙方的時間外，沒有任何好處。

二、不要預設前提，好比太相信本身的某些功能或配置必定沒有錯，相信我，大部分錯誤都是很愚蠢的。

最後，各位同窗不妨到個人公衆號裏互動一下 : 古時的風箏 ，進入公衆號能夠加入交流羣