提問的智慧
hello，小夥伴們大家好，今天給大家推薦一個給大家帶來成長的文章，提問題的智慧。在黑客的世界裏，當你拋出一個技術問題時，最終是否能得到有用的回答，往往取決於你所提問和追問的方式。這個項目將教你如何正確的提問以獲得你滿意的答案。
目錄
聲明
許多項目在他們的使用協助/說明網頁中鏈接了本指南，這麼做很好，我們也鼓勵大家都這麼做。但如果你是負責管理這個項目網頁的人，請在超鏈接附近的顯著位置上註明：
本指南不提供此項目的實際支持服務！
我們已經深刻領教到少了上述聲明所帶來的痛苦。因爲少了這點聲明，我們不停地被一些白癡糾纏。這些白癡認爲既然我們發佈了這本指南，那麼我們就有責任解決世上所有的技術問題。
如果你是因爲需要某些協助而正在閱讀這本指南，並且最後離開是因爲發現從本指南作者們身上得不到直接的協助，那麼你就是我們所說的那些白癡之一。別問我們問題，我們只會忽略你。我們在這本指南中是教你如何從那些真正懂得你所遇到軟件或硬件問題的人取得協助，而 99% 的情況下那不會是我們。除非你確定本指南的作者之一剛好是你所遇到的問題領域的專家，否則請不要打擾我們，這樣大家都會開心一點。
簡介
在黑客的世界裏，當你拋出一個技術問題時，最終是否能得到有用的回答，往往取決於你所提問和追問的方式。本指南將教你如何正確的提問以獲得你滿意的答案。
不只是黑客，現在開源（Open Source）軟件已經相當盛行，你常常也可以由其他有經驗的使用者身上得到好答案，這是件好事；使用者比起黑客來，往往對那些新手常遇到的問題更寬容一些。然而，將有經驗的使用者視爲黑客，並採用本指南所提的方法與他們溝通，同樣也是能從他們身上得到滿意回答的最有效方式。
首先你應該明白，黑客們喜愛有挑戰性的問題，或者能激發他們思維的好問題。如果我們並非如此，那我們也不會成爲你想詢問的對象。如果你給了我們一個值得反覆咀嚼玩味的好問題，我們自會對你感激不盡。好問題是激勵，是厚禮。好問題可以提高我們的理解力，而且通常會暴露我們以前從沒意識到或者思考過的問題。對黑客而言，"好問題！"是誠摯的大力稱讚。
儘管如此，黑客們有着蔑視或傲慢面對簡單問題的壞名聲，這有時讓我們看起來對新手、無知者似乎較有敵意，但其實不是那樣的。
我們不諱言我們對那些不願思考、或者在發問前不做他們該做的事的人的蔑視。那些人是時間殺手 —— 他們只想索取，從不付出，消耗我們可用在更有趣的問題或更值得回答的人身上的時間。我們稱這樣的人爲 失敗者（擼瑟） （由於歷史原因，我們有時把它拼作 lusers）。
我們意識到許多人只是想使用我們寫的軟件，他們對學習技術細節沒有興趣。對大多數人而言，電腦只是種工具，是種達到目的的手段而已。他們有自己的生活並且有更要緊的事要做。我們瞭解這點，也從不指望每個人都對這些讓我們着迷的技術問題感興趣。儘管如此，我們回答問題的風格是指向那些真正對此有興趣並願意主動參與解決問題的人，這一點不會變，也不該變。如果連這都變了，我們就是在降低做自己最擅長的事情上的效率。
我們（在很大程度上）是自願的，從繁忙的生活中抽出時間來解答疑惑，而且時常被提問淹沒。所以我們無情的濾掉一些話題，特別是拋棄那些看起來像失敗者的傢伙，以便更高效的利用時間來回答贏家（winner）的問題。
如果你厭惡我們的態度，高高在上，或過於傲慢，不妨也設身處地想想。我們並沒有要求你向我們屈服 —— 事實上，我們大多數人非常樂意與你平等地交流，只要你付出小小努力來滿足基本要求，我們就會歡迎你加入我們的文化。但讓我們幫助那些不願意幫助自己的人是沒有效率的。無知沒有關係，但裝白癡就是不行。
所以，你不必在技術上很在行才能吸引我們的注意，但你必須表現出能引導你變得在行的特質 – 機敏、有想法、善於觀察、樂於主動參與解決問題。如果你做不到這些使你與衆不同的事情，我們建議你花點錢找家商業公司籤個技術支持服務合同，而不是要求黑客個人無償地幫助你。
如果你決定向我們求助，當然你也不希望被視爲失敗者，更不願成爲失敗者中的一員。能立刻得到快速並有效答案的最好方法，就是像贏家那樣提問 – 聰明、自信、有解決問題的思路，只是偶爾在特定的問題上需要獲得一點幫助。
（歡迎對本指南提出改進意見。你可以 email 你的建議至 [email protected] 或 [email protected]。然而請注意，本文並非網絡禮節的通用指南，而我們通常會拒絕無助於在技術論壇得到有用答案的建議）。
在提問之前
在你準備要通過電子郵件、新聞羣組或者聊天室提出技術問題前，請先做到以下事情：
- 嘗試在你準備提問的論壇的舊文章中搜索答案。
- 嘗試上網搜索以找到答案。
- 嘗試閱讀手冊以找到答案。
- 嘗試閱讀常見問題文件（FAQ）以找到答案。
- 嘗試自己檢查或試驗以找到答案。
- 向你身邊的強者朋友打聽以找到答案。
- 如果你是程序開發者，請嘗試閱讀源代碼以找到答案。
當你提出問題的時候，請先表明你已經做了上述的努力；這將有助於樹立你並不是一個不勞而獲且浪費別人的時間的提問者。如果你能一併表達在做了上述努力的過程中所學到的東西會更好，因爲我們更樂於回答那些表現出能從答案中學習的人的問題。
運用某些策略，比如先用 Google 搜索你所遇到的各種錯誤信息（既搜索 Google 論壇，也搜索網頁），這樣很可能直接就找到了能解決問題的文件或郵件列表線索。即使沒有結果，在郵件列表或新聞組尋求幫助時加上一句 我在 Google 中搜過下列句子但沒有找到什麼有用的東西 也是件好事，即使它只是表明了搜索引擎不能提供哪些幫助。這麼做（加上搜索過的字串）也讓遇到相似問題的其他人能被搜索引擎引導到你的提問來。
彆着急，不要指望幾秒鐘的 Google 搜索就能解決一個複雜的問題。在向專家求助之前，再閱讀一下常見問題文件（FAQ）、放輕鬆、坐舒服一些，再花點時間思考一下這個問題。相信我們，他們能從你的提問看出你做了多少閱讀與思考，如果你是有備而來，將更有可能得到解答。不要將所有問題一股腦拋出，只因你的第一次搜索沒有找到答案（或者找到太多答案）。
準備好你的問題，再將問題仔細的思考過一遍，因爲草率的發問只能得到草率的回答，或者根本得不到任何答案。越是能表現出在尋求幫助前你爲解決問題所付出的努力，你越有可能得到實質性的幫助。
小心別問錯了問題。如果你的問題基於錯誤的假設，某個普通黑客（J. Random Hacker）多半會一邊在心裏想着蠢問題…， 一邊用無意義的字面解釋來答覆你，希望着你會從問題的回答（而非你想得到的答案）中汲取教訓。
絕不要自以爲夠格得到答案，你沒有；你並沒有。畢竟你沒有爲這種服務支付任何報酬。你將會是自己去掙到一個答案，靠提出有內涵的、有趣的、有思維激勵作用的問題 —— 一個有潛力能貢獻社區經驗的問題，而不僅僅是被動的從他人處索取知識。
另一方面，表明你願意在找答案的過程中做點什麼是一個非常好的開端。誰能給點提示？、我的這個例子裏缺了什麼？以及我應該檢查什麼地方比請把我需要的確切的過程貼出來更容易得到答覆。因爲你表現出只要有人能指個正確方向，你就有完成它的能力和決心。
精確地描述問題並言之有物
- 仔細、清楚地描述你的問題或 Bug 的症狀。
- 描述問題發生的環境（機器配置、操作系統、應用程序、以及相關的信息），提供經銷商的發行版和版本號（如：Fedora Core 4、Slackware 9.1等）。
- 描述在提問前你是怎樣去研究和理解這個問題的。
- 描述在提問前爲確定問題而採取的診斷步驟。
- 描述最近做過什麼可能相關的硬件或軟件變更。
- 儘可能的提供一個可以重現這個問題的可控環境的方法。
儘量去揣測一個黑客會怎樣反問你，在你提問之前預先將黑客們可能遇到的問題回答一遍。
以上幾點中，當你報告的是你認爲可能在代碼中的問題時，給黑客一個可以重現你的問題的環境尤其重要。當你這麼做時，你得到有效的回答的機會和速度都會大大的提升。
Simon Tatham 寫過一篇名爲《如何有效的報告 Bug》的出色文章。強力推薦你也讀一讀。
話不在多而在精
你需要提供精確有內容的信息。這並不是要求你簡單的把成堆的出錯代碼或者資料完全轉錄到你的提問中。如果你有龐大而複雜的測試樣例能重現程序掛掉的情境，儘量將它剪裁得越小越好。
這樣做的用處至少有三點。 第一，表現出你爲簡化問題付出了努力，這可以使你得到回答的機會增加； 第二，簡化問題使你更有可能得到有用的答案； 第三，在精煉你的 bug 報告的過程中，你很可能就自己找到了解決方法或權宜之計。
描述問題症狀而非你的猜測
告訴黑客們你認爲問題是怎樣造成的並沒什麼幫助。（如果你的推斷如此有效，還用向別人求助嗎？），因此要確信你原原本本告訴了他們問題的症狀，而不是你的解釋和理論；讓黑客們來推測和診斷。如果你認爲陳述自己的猜測很重要，清楚地說明這只是你的猜測，並描述爲什麼它們不起作用。
蠢問題
我在編譯內核時接連遇到 SIG11 錯誤， 我懷疑某條飛線搭在主板的走線上了，這種情況應該怎樣檢查最好？
聰明問題
我的組裝電腦是 FIC-PA2007 主機板搭載 AMD K6/233 CPU（威盛 Apollo VP2 芯片組）， 256MB Corsair PC133 SDRAM 內存，在編譯內核時，從開機 20 分鐘以後就頻頻產生 SIG11 錯誤， 但是在頭 20 分鐘內從沒發生過相同的問題。重新啓動也沒有用，但是關機一晚上就又能工作 20 分鐘。 所有內存都換過了，沒有效果。相關部分的標準編譯記錄如下…。
由於以上這點似乎讓許多人覺得難以配合，這裏有句話可以提醒你：所有的診斷專家都來自密蘇里州。 美國國務院的官方座右銘則是：讓我看看（出自國會議員 Willard D. Vandiver 在 1899 年時的講話：我來自一個出產玉米，棉花，牛蒡和民主黨人的國家，滔滔雄辯既不能說服我，也不會讓我滿意。我來自密蘇里州，你必須讓我看看。） 針對診斷者而言，這並不是一種懷疑，而只是一種真實而有用的需求，以便讓他們看到的是與你看到的原始證據儘可能一致的東西，而不是你的猜測與歸納的結論。所以，大方的展示給我們看吧！
如何更好地回答問題
態度和善一點。問題帶來的壓力常使人顯得無禮或愚蠢，其實並不是這樣。
對初犯者私下回復。對那些坦誠犯錯之人沒有必要當衆羞辱，一個真正的新手也許連怎麼搜索或在哪找常見問題都不知道。
如果你不確定，一定要說出來！一個聽起來權威的錯誤回覆比沒有還要糟，別因爲聽起來像個專家很好玩，就給別人亂指路。要謙虛和誠實，給提問者與同行都樹個好榜樣。
如果幫不了忙，也別妨礙他。不要在實際步驟上開玩笑，那樣也許會毀了使用者的設置 —— 有些可憐的呆瓜會把它當成真的指令。
試探性的反問以引出更多的細節。如果你做得好，提問者可以學到點東西 —— 你也可以。試試將蠢問題轉變成好問題，別忘了我們都曾是新手。
儘管對那些懶蟲抱怨一聲 RTFM 是正當的，能指出文件的位置（即使只是建議個 Google 搜索關鍵詞）會更好。
如果你決定回答，就請給出好的答案。當別人正在用錯誤的工具或方法時別建議笨拙的權宜之計（wordaround），應推薦更好的工具，重新界定問題。
正面的回答問題！如果這個提問者已經很深入的研究而且也表明已經試過 X 、 Y 、 Z 、 A 、 B 、 C 但沒得到結果，回答 試試看 A 或是 B 或者 試試 X 、 Y 、 Z 、 A 、 B 、 C 並附上一個鏈接一點用都沒有。
幫助你的社區從問題中學習。當回覆一個好問題時，問問自己如何修改相關文件或常見問題文件以免再次解答同樣的問題？，接着再向文件維護者發一份補丁。
如果你是在研究一番後才做出的回答，展現你的技巧而不是直接端出結果。畢竟授人以魚不如授人以漁。
項目地址：https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/master/README-zh_CN.md
今天的推薦不知道大家喜歡嗎？如果你們喜歡話，請在文章底部留言或點贊，以表示對我的支持，你們的留言，點贊，轉發關注是我持續更新的動力哦！
關注我的公衆號回覆："1024"，免費領取一大波學習資源，先到先得哦！
