如何在 Stack Overflow 規範提問

• 2019 年 11 月 8 日
• 筆記

前言：

最近學習js的時候看到了一段程式碼，思考再三之後仍然不是很理解，於是決定到儘可能多的平台進行提問，目的有二：1.最主要的，解決問題；2.借這個機會測試哪些平台可以在短時間內給予提問者回饋和援助，從而作為下次提問的首選之地。最後問題是解決了，但是關於提問這件事再次有了不一樣的感想。

首先從我自身出發—-在中文環境下我能夠做到比較規範的提問（我認為的規範），即

• 表訴清晰
• 必要的答謝

但是在英文環境下就顯得吃力得多，暴露的缺點如下：

• 表達不夠地道清晰，誤導了回答者，導致問題被認為是duplicate而被關閉
• 編輯問題後未進行必要的核查，導致了後期的修改
• 無法完全理解對方想要表達的意思

其次從平台出發進行分析，不得不說中國的平台回饋速度和熱情的確比不上國外的。知乎因為有邀請機制，所以問題還是有機會得到高手的點撥；SegmentFault本身定位就是中國的Stack Overflow，所以得到專業回答的可能性也比較大。 但是類似貼吧和QQ群這些交流平台，得到有效回答的機率卻實在太低。本來QQ群是實時互動的，回饋更應該迅速點，但是很多時候問題會被忽略。是什麼原因我就不說了，不好直接下定論，但這無疑提示了我：如果急著解決問題，就應該避免在這些地方浪費時間—-一來速度沒保障，二來品質參差不齊。

理想的提問平台應該是SegmentFault或者Stack Overflow。關於如何在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不是論壇， 它的目標是希望成為編程類問答的一個超級資料庫， 所以每個問題都不止是為了幫助提問者本人， 更重要的是希望將來能夠幫助到每一個遇到同樣問題的人。

所以， 和問題無關的內容都被認為是一種噪音， 包括： 打招呼（比如 Hi, Hello， Good afternoon， Dear Coders等)， 表示感謝（比如 Thanks, Any help would be appreciated等)， 沒必要的背景（比如 I』m a newbie in C#等)， 你的簽名 等。 可能有人會不理解為什麼這樣規定， 尤其是不要表示感謝這點。 Stack Overflow社區的理由是， 對願意閱讀並嘗試解答你問題的人來說， 最好的表達感謝的方式是upvote有幫助的回答， 以及選擇其中一個作為答案。 每一句和問題無關的內容都增加了額外的閱讀時間， 而一個問題可能會被大量的人閱讀。 更多的相關討論可以參見這裡和這裡。

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

英語

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

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

內容

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

• 你做過足夠的研究么？ 有的人連入門指南都沒讀上10分鐘就去提問， 問的問題能有多少價值呢？
• 你嘗試過搜索么？ 至少要試過Google和站內搜索， 很可能相同的問題已經有答案了
• 你試過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 即可。

交流

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

術語辭彙

2019.5.3 更：

近期找到了一個更好的平台（掘金翻譯計劃），它擁有完善的流程把控和工作分配，這其實正是我很久以前試圖在漢化工作中尋找但是沒有找到的東西。其實這是一件值得長期投資的事情：

1.最主要的目的，鍛煉閱讀英文技術文檔的能力，同時積累術語辭彙； 2.熟悉 github 的操作 3.據說 200 積分可以換一台kindle（雖然聽起來遙遙無期，但是可以作為動力哈哈哈）

當然，這個工作不會很輕鬆，不過完事開頭難是很正常的，希望我可以堅持下去吧。