Stack Overflow是世界上最大的程式設計類問答網站， 大多數程式設計師或多或少和它有所接觸： 即使你從來沒有在它上面提問或回答過， 別忘了， 在搜尋很多技術問題的時候， 結果的第一頁往往就有幾條連結到Stack Overflow的問題。

很多人對於Stack Overflow的第一印象是： 很多程式設計問題都能在上面找到專業的答案， 太牛了。 但當問題沒有找到合適答案, 而去上面提新問題的時候， 可能有人會發現自己的問題被殘忍的 downvote，甚至被關閉、最後被刪除。更有甚者， 發現自己被禁言了， 不允許再問問題。 這是Stack Overflow的另一面： 在一定程度上它對新手是很不友好的。

我個人是Stack Overflow的活躍使用者（這個就是我）， 目前 reputation 超過 80K， 參與過很多的關閉/刪除問題的投票（關閉問題需要5個rep超過3K的使用者投票 ， 刪除問題需要3個或更多rep超過10K的使用者投票 ）。寫這篇文章， 是為了分享一下我的經驗， 講講如何有效的在Stack Overflow上問問題。

可以問什麼樣的主題

大家都知道 Stack Overflow是程式設計類的問答社群， 但還真有人把它當成通用的問答社群了， 問些完全無關的問題。 其實， Stack Overflow 是有一系列兄弟網站的（目前已經有100+)， 統稱 Stack Exchange， 涵蓋很多主題， 比如數學、物理、化學等科學類， 伺服器管理、Latex、資料庫等計算機類， 中文、俄文、日文等語言類， 詳細的列表看這裡， 不要讓好問題問錯地方哦。

允許的主題包括： 具體的程式設計問題、軟體演算法相關、通常只有程式設計師用的軟體工具相關等。

有些主題是比較容易弄錯的， 比如一般的電腦操作問題， 應該去Super User(熱門的 Linux/Unix, 和Ubuntu還有獨立的站點）， 專業的伺服器問題， 應該去Server Fault。這些都不屬於程式設計類的問題， 儘管不少程式設計師的日常工作也有涉及（想一想“怎麼修電腦？”屬於程式設計問題麼）。 再舉個例子， 同樣是編輯器， Vim/Emacs/Atom相關的問題是可以的，因為基本只有程式設計師會用這些工具， 而 Word/記事本相關的一般就不可以。

什麼樣的問題應該避免問

程式設計相關還不夠， Stack Overflow 要求問題必須是 「practical, answerable questions based on actual problems that you face」。

這是什麼意思呢？ 首先， 開放式的問題是不允許的，比如“你為什麼喜歡PHP?”， 隔壁Quora會是更合適的物件。 其次， 問題應該不需要很長的篇幅來回答， 如果一個問題期待的回答足夠寫一本書， 那很可能會被關閉的。 各種尋求資源的問題應該避免，如 “要完成某某工作， 有什麼Python的庫可以用”， 或者“學習C++應該選擇哪本書？”等， 因為答案會主觀， 也容易吸引廣告。 最後， 問題不要基於憑空的假設，要基於實際的難題。

需要注意的是，你很可能見過一些違反上面規定的問題還在，而且瀏覽量很大， 尤其是一些尋求資源的問題， 和非程式設計相關的計算機問題等。 這是什麼原因呢？ 原來，早期的Stack Overflow的規則還比較鬆，也沒有Super User之類的站點。 這些問題往往是08/09年問的，大多數現在已經被關閉了。

上面的規則如果遵守， 你的問題應該問對地方了。 下面繼續說說內容上具體需要注意的。

直入主題

Stack Overflow不是論壇， 它的目標是希望成為程式設計類問答的一個超級資料庫， 所以每個問題都不止是為了幫助提問者本人， 更重要的是希望將來能夠幫助到每一個遇到同樣問題的人。

可能有人會不理解為什麼這樣規定， 尤其是不要表示感謝這點。 Stack Overflow社群的理由是， 對願意閱讀並嘗試解答你問題的人來說， 最好的表達感謝的方式是upvote有幫助的回答， 以及選擇其中一個作為答案。 每一句和問題無關的內容都增加了額外的閱讀時間， 而一個問題可能會被大量的人閱讀。 更多的相關討論可以參見這裡和這裡。

同樣道理， 當有人回答你的問題之後， 也不要去新增無用的評論， 比如單純的表達感謝的話， “+1”， 或者閒聊等。 評論的唯一用處是用來澄清疑問。

英語

作為一個英語社群， 不論提問、回答還是在評論中和別人互動， 都是要用英語的。

除非英語水平真的很糟糕， 語法其實並不是最需要擔心的，因為並不需要做到完美。Stack Overflow是允許自由的編輯其他人的問題/回答的（編輯者如果rep不到2K，需要經過評審才會生效）。 有很多人會熱情的對問題進行編輯的， 包括修復可能的語法錯誤。 我想說的一點是， 要儘可能的保證單詞拼寫是正確的。 即使對英語不夠好的人來說， 這也只需要多花一點時間檢查就可以做到， 但它代表著對閱讀你問題的人的尊重。 甚至很多英語母語的人在拼寫上也不注意， 會把I’m 寫成im, 把 want to寫成 wanna之類的非正式英語， 這些都會降低問題被回答的概率。

內容

在發問題之前， 問自己幾個問題：

1. 你做過足夠的研究麼？ 有的人連入門指南都沒讀上10分鐘就去提問， 問的問題能有多少價值呢？
2. 你嘗試過搜尋麼？ 至少要試過Google和站內搜尋， 很可能相同的問題已經有答案了
3. 你試過debug麼？ 把你的想法或除錯過程寫在問題裡，否則很可能會看到幾條評論“Have you tried anything?”或“We don’t do your homework”之後問題就被downvote得慘不忍睹了。 因為大多數人是拒絕回答沒有努力嘗試的提問者的。

標籤： 一個問題可以加1~5個標籤， 大多數問題是和某種具體的程式語言相關的， 這個語言的標籤通常是必須的， 否則相關語言的關注者們很可能根本見不到問題。

起一個好標題： 一般來說， 標題應該儘量用簡介的語言描述具體的問題。 比如 C# number confusion就是個反例， 如果改成 Why does using float instead of int give me different results when all of my inputs are integers? 就要具體多了。

提供程式碼

對於程式設計類問題，的確有問題不需要程式碼也能表達清楚的， 但大多數問題都需要程式碼才能清晰的表達。“我宣告瞭一個變數， 呼叫了幾個函式， 然後它的值就變了， 為什麼呢？” 這樣的問題， 鬼才知道答案。

提供程式碼要注意： 不要貼截圖， 難道你要回答者去照著截圖敲鍵盤復現你的問題？ 也不要只貼站外的連結， 如果站外連結能夠提供一些額外的方便功能， 也要在貼程式碼的基礎上附上該連結。

對於提供什麼樣的程式碼， Stack Overflow給出了一個可參考的標準： MCVE， 即Minimal, Complete, and Verifiable example

• Minimal: 最小的， 也就是儘可能的去掉和問題無關的部分。 如果你貼了一個幾百行的程式碼， 很少有人願意花時間去仔細看。 構造最小化例子的過程本身也是debug的過程。
• Complete: 完整的， 一個簡單的判斷是：別人看到問題， 可以通過複製你提供的程式碼復現出問題嗎？
• Verifiable: 可驗證， 描述問題儘可能具體， “the code doesn’t work”這樣的描述就很不好。 如果編譯不過， 要加上編譯錯誤資訊； 如果執行報錯， 也同樣要加上具體的錯誤資訊； 如果結果和你的預期不一致， 要說清楚你的預期結果是什麼， 為什麼會這樣想。

格式

Stack Overflow的編輯器是Markdown格式的， 如果你還不熟悉， 建議去學一下， 因為Markdown真的是一個只要10分鐘就可以學會的語言。

大多數的格式問題都是出在貼程式碼的地方， 如果你發現你的程式碼是普通文字， 而沒有語法高亮等功能， 那你很可能是格式搞錯了。 最方便的方法就是選擇所有程式碼， 然後按鍵盤Ctrl + K 即可。

交流

有可能你的問題幾分鐘內就會有人回答， 也有可能有人對問題有疑問， 在評論中要求你解釋。 可以評論@他們解釋， 如果問題確實不夠清晰， 編輯你的問題吧。 最後， 如果你自己發現瞭解答方法， 而還沒人給出， 那就自己回答自己的問題吧。 自問自答是被鼓勵的行為。

結語

看完上面我的嘮叨， 是不是也感覺到Stack Overflow對新手的不友好了呢？ 但這是保持高質量內容的代價之一， 必須有一定的機制讓低質量的問題不會氾濫， 才會有更多的人願意花時間回答好的問題。 希望大家都能得到自己問題的答案， 有機會再講講如何回答問題。

打賞支援我寫出更多好文章，謝謝！

打賞作者