【轉】編程世界經典祕籍：程序員的提問之道

根原帖：https://www.oschina.net/news/85992/how-to-ask-questions-the-smart-wa

本站原貼：https://news.cnblogs.com/n/572032/

本文節選於編程世界裏很是經典的一份文檔，該文檔首發於 2001 年，已通過屢次迭代更新，詳細描述了程序員應該如何在網上有禮貌地、合理地向別人提問以及如何解讀答案，好比本身先作足功課：搜索、讀文檔、讀代碼等。如下中文版節選是由 ryanhanwu 基於原文 3.10 版的最新翻譯，全文較長，有興趣的可跳轉查看完整內容。

　　簡介

　　在黑客的世界裏，當你拋出一個技術問題時，最終是否能獲得有用的回答，每每取決於你所提問和追問的方式。本指南將教你如何正確的提問以得到你滿意的答案。

　　不僅是黑客，如今開放源代碼（Open Source）軟件已經至關盛行，你經常也能夠由其餘有經驗的使用者身上獲得好答案，這是件_好事_；使用者比起黑客來，每每對那些新手常遇到的問題更寬容一些。然而，將有經驗的使用者視爲黑客，並採用本指南所提的方法與他們溝通，一樣也是能從他們身上獲得滿意回答的最有效方式。

　　首先你應該明白，黑客們喜好有挑戰性的問題，或者能激發咱們思惟的好問題。若是咱們並不是如此，那咱們也不會成爲你想詢問的對象。若是你給了咱們一個值得反覆咀嚼玩味的好問題，咱們自會對你感激涕零。好問題是激勵，是厚禮。好問題能夠提升咱們的理解力，並且一般會暴露咱們之前從沒意識到或者思考過的問題。對黑客而言，"好問題！"是誠摯的大力稱讚。

　　儘管如此，黑客們有着蔑視或傲慢面對簡單問題的壞名聲，這有時讓咱們看起來對新手、無知者彷佛較有敵意，但其實不是那樣的。

　　咱們不諱言咱們對那些不肯思考、或者在發問前不作他們該作的事的人的蔑視。那些人是時間殺手 -– 他們只想索取，從不付出，消耗咱們可用在更有趣的問題或更值得回答的人身上的時間。咱們稱這樣的人爲 失敗者（擼瑟） （因爲歷史緣由，咱們有時把它拼做 lusers）。

　　在提問以前

　　在你準備要經過電子郵件、新聞羣組或者聊天室提出技術問題前，請先作到如下事情：

1. 嘗試在你準備提問的論壇的舊文章中搜索答案。

2. 嘗試上網搜索以找到答案。

3. 嘗試閱讀手冊以找到答案。

4. 嘗試閱讀常見問題文件（FAQ）以找到答案。

5. 嘗試本身檢查或試驗以找到答案

6. 向你身邊的強者朋友打聽以找到答案。

7. 若是你是程序開發者，請嘗試閱讀源代碼以找到答案。

　　當你提出問題的時候，請先代表你已經作了上述的努力；這將有助於樹立你並非一個坐享其成且浪費別人的時間的提問者。若是你能一併表達在作了上述努力的過程當中所_學到_的東西會更好，由於咱們更樂於回答那些表現出能從答案中學習的人的問題。

　　運用某些策略，好比先用 Google 搜索你所遇到的各類錯誤信息（既搜索 Google 論壇，也搜索網頁），這樣極可能直接就找到了能解決問題的文件或郵件列表線索。即便沒有結果，在郵件列表或新聞組尋求幫助時加上一句 我在 Google 中搜過下列句子但沒有找到什麼有用的東西 也是件好事，即便它只是代表了搜索引擎不能提供哪些幫助。這麼作（加上搜索過的字串）也讓遇到類似問題的其餘人能被搜索引擎引導到你的提問來。

　　彆着急，不要期望幾秒鐘的 Google 搜索就能解決一個複雜的問題。在向專家求助以前，再閱讀一下常見問題文件（FAQ）、放輕鬆、坐舒服一些，再花點時間思考一下這個問題。相信咱們，他們能從你的提問看出你作了多少閱讀與思考，若是你是有備而來，將更有可能獲得解答。不要將全部問題一股腦拋出，只因你的第一次搜索沒有找到答案（或者找到太多答案）。

　　準備好你的問題，再將問題仔細的思考過一遍，由於草率的發問只能獲得草率的回答，或者根本得不到任何答案。越是能表現出在尋求幫助前你爲解決問題所付出的努力，你越有可能獲得實質性的幫助。

　　當心別問錯了問題。若是你的問題基於錯誤的假設，某個普通黑客（J. Random Hacker）多半會一邊在內心想着蠢問題…， 一邊用無心義的字面解釋來答覆你，但願着你會從問題的回答（而非你想獲得的答案）中汲取教訓。

　　毫不要自覺得_夠格_獲得答案，你沒有；你並無。畢竟你沒有爲這種服務支付任何報酬。你將會是本身去_掙到_一個答案，靠提出有內涵的、有趣的、有思惟激勵做用的問題 --一個有潛力能貢獻社區經驗的問題，而不只僅是被動的從他人處索取知識。

　　另外一方面，代表你願意在找答案的過程當中作點什麼是一個很是好的開端。誰能給點提示？、個人這個例子裏缺了什麼？以及我應該檢查什麼地方比請把我須要的確切的過程貼出來更容易獲得答覆。由於你表現出只要有人能指個正確方向，你就有完成它的能力和決心。

　　當你提問時

　　慎選提問的論壇

　　當心選擇你要提問的場合。若是你作了下述的事情，你極可能被忽略掉或者被看做失敗者：

• 在與主題不合的論壇上貼出你的問題

• 在探討進階技術問題的論壇張貼很是初級的問題；反之亦然

• 在太多的不一樣新聞羣組上重複轉貼一樣的問題（cross-post）

• 向既非熟人也沒有義務解決你問題的人發送私人電郵

　　黑客會剔除掉那些搞錯場合的問題，以保護他們溝通的渠道不被無關的東西淹沒。你不會想讓這種事發生在本身身上的。

　　所以，第一步是找到對的論壇。再說一次，Google 和其它搜索引擎仍是你的朋友，用它們來找到與你遭遇到困難的軟硬件問題最相關的網站。一般那兒都有常見問題（FAQ）、郵件列表及相關說明文件的連接。若是你的努力（包括_閱讀_ FAQ）都沒有結果，網站上也許還有報告 Bug（Bug-reporting）的流程或連接，若是是這樣，鏈過去看看。

　　向陌生的人或論壇發送郵件最多是風險最大的事情。舉例來講，別假設一個提供豐富內容的網頁的做者會想充當你的免費顧問。不要對你的問題是否會受到歡迎作太樂觀的估計 -- 若是你不肯定，那就向別處發送，或者壓根別發。

　　在選擇論壇、新聞羣組或郵件列表時，別太相信名字，先看看 FAQ 或者許可書以弄清楚你的問題是否切題。發文前先翻翻已有的話題，這樣可讓你感覺一下那裏的文化。事實上，事先在新聞組或郵件列表的歷史記錄中搜索與你問題相關的關鍵詞是個極好的主意，也許這樣就找到答案了。即便沒有，也能幫助你概括出更好的問題。

　　別像機關槍似的一次"掃射"全部的幫助渠道，這就像大喊大叫同樣會令人不快。要一個一個地來。

　　搞清楚你的主題！最典型的錯誤之一是在某種致力於跨平臺可移植的語言、套件或工具的論壇中提關於 Unix 或 Windows 操做系統程序界面的問題。若是你不明白爲何這是大錯，最好在搞清楚這之間差別以前什麼也別問。

　　通常來講，在仔細挑選的公共論壇中提問，會比在私有論壇中提一樣的問題更容易獲得有用的回答。有幾個理由能夠支持這點，一是看潛在的回覆者有多少，二是看觀衆有多少。黑客較願意回答那些能幫助到許多人的問題。

　　能夠理解的是，老練的黑客和一些熱門軟件的做者正在接受過多的錯發信息。就像那根最後壓垮駱駝背的稻草同樣，你的加入也有可能使狀況走向極端 -- 已經好幾回了，一些熱門軟件的做者從本身軟件的支持中抽身出來，由於伴隨而來涌入其私人郵箱的無用郵件變得沒法忍受。

　　Stack Overflow

　　搜索，而後 在 Stack Exchange 問。

　　近年來，Stack Exchange community 社區已經成爲回答技術及其餘問題的主要渠道，尤爲是那些開放源碼的項目。

　　由於 Google 索引是即時的，在看 Stack Exchange 以前先在 Google 搜索。有很高的機率某人已經問了一個相似的問題，並且 Stack Exchange 網站們每每會是搜索結果中最前面幾個。若是你在 Google 上沒有找到任何答案，你再到特定相關主題的網站去找。用標籤（Tag）搜索能讓你更縮小你的搜索結果。

　　Stack Exchange 已經成長到超過一百個網站，如下是最經常使用的幾個站：

• Super User 是問一些通用的電腦問題，若是你的問題跟代碼或是寫程序無關，只是一些網絡連線之類的，請到這裏。

• Stack Overflow 是問寫程序有關的問題。

• Server Fault 是問服務器和網管相關的問題。

　　網站和 IRC 論壇

　　本地的使用者羣組（user group），或者你所用的 Linux 發行版本也許正在宣傳他們的網頁論壇或 IRC 頻道，並提供新手幫助（在一些非英語國家，新手論壇極可能仍是郵件列表）， 這些地方是開始提問的好首選，特別是當你以爲遇到的也許只是相對簡單或者很普通的問題時。有廣告贊助的 IRC 頻道是公開歡迎提問的地方，一般能夠即時獲得迴應。

　　事實上，若是程序出的問題只發生在特定 Linux 發行版提供的版本（這很常見），最好先去該發行版的論壇或郵件列表中提問，再到程序自己的論壇或郵件列表提問。（不然）該項目的黑客可能僅僅回覆 "用_咱們的_版本"。

　　在任何論壇發文之前，先確認一下有沒有搜索功能。若是有，就試着搜索一下問題的幾個關鍵詞，也許這會有幫助。若是在此以前你已作過通用的網頁搜索（你也該這樣作），仍是再搜索一下論壇，搜索引擎有可能沒來得及索引此論壇的所有內容。

　　經過論壇或 IRC 頻道來提供使用者支持服務有增加的趨勢，電子郵件則大多爲項目開發者間的交流而保留。因此最好先在論壇或 IRC 中尋求與該項目相關的協助。

　　在使用 IRC 的時候，首先最好不要發佈很長的問題描述，有些人稱之爲頻道洪水。最好經過一句話的問題描述來開始聊天。

　　第二步，使用項目郵件列表

　　當某個項目提供開發者郵件列表時，要向列表而不是其中的個別成員提問，即便你確信他能最好地回答你的問題。查一查項目的文件和首頁，找到項目的郵件列表並使用它。有幾個很好的理由支持咱們採用這種辦法：

• 任何好到須要向個別開發者提出的問題，也將對整個項目羣組有益。反之，若是你認爲本身的問題對整個項目羣組來講太愚蠢，也不能成爲騷擾個別開發者的理由。

• 向列表提問能夠分散開發者的負擔，個別開發者（尤爲是項目領導人）也許太忙以致於無法回答你的問題。

• 大多數郵件列表都會被存檔，那些被存檔的內容將被搜索引擎索引。若是你向列表提問並獲得解答，未來其它人能夠經過網頁搜索找到你的問題和答案，也就不用再次發問了。

• 若是某些問題常常被問到，開發者能夠利用此信息來改進說明文件或軟件自己，以使其更清楚。若是隻是私下提問，就沒有人能看到最多見問題的完整場景。

　　若是一個項目既有"使用者" 也有"開發者"（或"黑客"）郵件列表或論壇，而你又不會動到那些源代碼，那麼就向"使用者"列表或論壇提問。不要假設本身會在開發者列表中受到歡迎，那些人多半會將你的提問視爲干擾他們開發的噪音。

　　然而，若是你_確信_你的問題很特別，並且在"使用者" 列表或論壇中幾天都沒有回覆，能夠試試前往"開發者"列表或論壇發問。建議你在張貼前最好先暗地裏觀察幾天以瞭解那裏的行事方式（事實上這是參與任何私有或半私有列表的好主意）

　　若是你找不到一個項目的郵件列表，而只能查到項目維護者的電子郵件地址，儘管向他發信。即便是在這種狀況下，也別假設（項目）郵件列表不存在。在你的電子郵件中，請陳述你已經試過但沒有找到合適的郵件列表，也說起你不反對將本身的郵件轉發給他人（許多人認爲，即便沒什麼祕密，私人電子郵件也不該該被公開。經過容許將你的電子郵件轉發他人，你給了相應人員處置你郵件的選擇）。

　　使用有意義且描述明確的標題

　　在郵件列表、新聞羣組或論壇中，大約 50 字之內的標題是抓住資深專家注意力的好機會。別用喋喋不休的幫幫忙、跪求、急（更別說救命啊！！！！這樣讓人反感的話，用這種標題會被條件反射式地忽略）來浪費這個機會。不要妄想用你的痛苦程度來打動咱們，而應該是在這點空間中使用極簡單扼要的描述方式來提出問題。

　　一個好標題範例是目標 -- 差別式的描述，許多技術支持組織就是這樣作的。在目標部分指出是哪個或哪一組東西有問題，在差別部分則描述與指望的行爲不一致的地方。

蠢問題：救命啊！個人筆記本電腦不能正常顯示了！

聰明問題：X.org 6.8.1 的鼠標光標會變形，某牌顯卡 MV1005 芯片組。

更聰明問題：X.org 6.8.1 的鼠標光標，在某牌顯卡 MV1005 芯片組環境下 - 會變形。

　　編寫目標 -- 差別 式描述的過程有助於你組織對問題的細緻思考。是什麼被影響了？ 僅僅是鼠標光標或者還有其它圖形？只在 X.org 的 X 版中出現？或只是出如今 6.8.1 版中？ 是針對某牌顯卡芯片組？或者只是其中的 MV1005 型號？ 一個黑客只需瞄一眼就可以當即明白你的環境_和_你遇到的問題。

　　總而言之，請想像一下你正在一個只顯示標題的存檔討論串（Thread）索引中查尋。讓你的標題更好地反映問題，可以使下一個搜索相似問題的人可以關注這個討論串，而不用再次提問相同的問題。

　　若是你想在回覆中提出問題，記得要修改內容標題，以代表你是在問一個問題， 一個看起來像 Re: 測試 或者 Re: 新 bug 的標題很難引發足夠重視。另外，在不影響連貫性之下，適當引用並刪減前文的內容，能給新來的讀者留下線索。

　　對於討論串，不要直接點擊回覆來開始一個全新的討論串，這將限制你的觀衆。由於有些郵件閱讀程序，好比 mutt ，容許使用者按討論串排序並經過摺疊討論串來隱藏消息，這樣作的人永遠看不到你發的消息。

　　僅僅改變標題還不夠。mutt 和其它一些郵件閱讀程序還會檢查郵件標題之外的其它信息，以便爲其指定討論串。因此寧肯發一個全新的郵件。

　　在網頁論壇上，好的提問方式稍有不一樣，由於討論串與特定的信息緊密結合，而且一般在討論串外就看不到裏面的內容，故經過回覆提問，而非改變標題是可接受的。不是全部論壇都容許在回覆中出現分離的標題，並且這樣作了基本上沒有人會去看。不過，經過回覆提問，這自己就是曖昧的作法，由於它們只會被正在查看該標題的人讀到。因此，除非你_只想_在該討論串當前活躍的人羣中提問，否則仍是另起爐竈比較好。

　　使問題容易回覆

　　以請將你的回覆寄到……來結束你的問題多半會使你得不到回答。若是你以爲花幾秒鐘在郵件客戶端設置一下回復地址都麻煩，咱們也以爲花幾秒鐘思考你的問題更麻煩。若是你的郵件程序不支持這樣作，換個好點的；若是是操做系統不支持這種郵件程序，也換個好點的。

　　在論壇，要求經過電子郵件回覆是很是無禮的，除非你相信回覆的信息可能比較敏感（並且有人會爲了某些未知的緣由，只讓你而不是整個論壇知道答案）。若是你只是想在有人回覆討論串時獲得電子郵件提醒，能夠要求網頁論壇發送給你。幾乎全部論壇都支持諸如追蹤此討論串、有回覆時發送郵件提醒等功能。

　　用清晰、正確、精準並語法正確的語句

　　咱們從經驗中發現，粗心的提問者一般也會粗心的寫程序與思考（我敢打包票）。回答粗枝大葉者的問題很不值得，咱們寧願把時間耗在別處。

　　正確的拼字、標點符號和大小寫是很重要的。通常來講，若是你以爲這樣作很麻煩，不想在意這些，那咱們也以爲麻煩，不想在意你的提問。花點額外的精力斟酌一下字句，用不着太僵硬與正式 -- 事實上，黑客文化很看重能準確地使用非正式、俚語和幽默的語句。但它_必須很_準確，並且有跡象代表你是在思考和關注問題。

　　正確地拼寫、使用標點和大小寫，不要將its混淆爲it's，loose搞成lose或者將discrete弄成discreet。不要所有用大寫，這會被視爲無禮的大聲嚷嚷（所有小寫也好不到哪去，由於不易閱讀。Alan Cox 也許能夠這樣作，但你不行。）

　　更白話的說，若是你寫得像是個半文盲[譯註：小白]，那多半得不到理睬。也不要使用即時通信中的簡寫或火星文，如將的簡化爲ㄉ會使你看起來像一個爲了少打幾個鍵而省字的小白。更糟的是，若是像個小孩似地鬼畫符那絕對是在找死，能夠確定沒人會理你（或者最可能是給你一大堆指責與挖苦）。

　　若是在使用非母語的論壇提問，你能夠犯點拼寫和語法上的小錯，但決不能在思考上馬虎（沒錯，咱們一般能弄清二者的分別）。同時，除非你知道回覆者使用的語言，不然請使用英語書寫。繁忙的黑客通常會直接刪除用他們看不懂語言寫的消息。在網絡上英語是通用語言，用英語書寫能夠將你的問題在還沒有被閱讀就被直接刪除的可能性降到最低。

　　若是英文是你的外語（Second language），提示潛在回覆者你有潛在的語言困難是很好的： [譯註：如下附上原文以供使用]

English is not my native language; please excuse typing errors.

• 英文不是個人母語，請原諒個人錯字或語法

If you speak $LANGUAGE, please email/PM me; I may need assistance translating my question.

• 若是你說某語言，請寄信/私訊給我；我須要有人協助我翻譯個人問題

I am familiar with the technical terms, but some slang expressions and idioms are difficult for me.

• 我對技術名詞很熟悉，但對於俗語或是特別用法比較不甚瞭解。

I've posted my question in $LANGUAGE and English. I'll be glad to translate responses, if you only use one or the other.

• 我把個人問題用某語言和英文寫出來，若是你只用一種語言回答，我會樂意將其翻譯成另外一種。

　　使用易於讀取且標準的文件格式發送問題

　　若是你人爲地將問題搞得難以閱讀，它多半會被忽略，人們更願讀易懂的問題，因此：

• 使用純文字而不是 HTML (關閉 HTML 並不難）。

• 使用 MIME 附件一般是能夠的，前提是真正有內容（譬如附帶的源代碼或 patch），而不只僅是郵件程序生成的模板（譬如只是信件內容的拷貝）。

• 不要發送一段文字只是一行句子但自動換行後會變成多行的郵件（這使得回覆部份內容很是困難）。設想你的讀者是在 80 個字符寬的終端機上閱讀郵件，最好設置你的換行分割點小於 80 字。

• 可是，對一些特殊的文件_不要_設置固定寬度（譬如日誌檔案拷貝或會話記錄）。數據應該原樣包含，讓回覆者有信心他們看到的是和你看到的同樣的東西。

• 在英語論壇中，不要使用Quoted-Printable MIME 編碼發送消息。這種編碼對於張貼非 ASCII 語言多是必須的，但不少郵件程序並不支持這種編碼。當它們處理換行時，那些文本中四處散佈的=20符號既難看也分散注意力，甚至有可能破壞內容的語意。

• 絕對，_永遠_不要期望黑客們閱讀使用封閉格式編寫的文檔，像微軟公司的 Word 或 Excel 文件等。大多數黑客對此的反應就像有人將還在冒熱氣的豬糞倒在你家門口時你的反應同樣。即使他們可以處理，他們也很厭惡這麼作。

• 若是你從使用 Windows 的電腦發送電子郵件，關閉微軟愚蠢的智能引號功能 （從[選項] > [校正] > [自動校訂選項]，勾選掉智能引號單選框），以避免在你的郵件中處處散佈垃圾字符。

• 在論壇，勿濫用表情符號和HTML功能（當它們提供時）。一兩個表情符號一般沒有問題，但花哨的彩色文本傾向於令人認爲你是個無能之輩。過濫地使用表情符號、色彩和字體會使你看來像個傻笑的小姑娘。這一般不是個好主意，除非你只是對性而不是對答案感興趣。

　　若是你使用圖形用戶界面的郵件程序（如微軟公司的 Outlook 或者其它相似的），注意它們的默認設置不必定知足這些要求。大多數這類程序有基於選單的查看源代碼命令，用它來檢查發送文件夾中的郵件，以確保發送的是純文本文件同時沒有一些奇怪的字符。

　　精確的描述問題並言之有物

• 仔細、清楚地描述你的問題或 Bug 的症狀。

• 描述問題發生的環境（機器配置、操做系統、應用程序、以及相關的信息），提供經銷商的發行版和版本號（如：Fedora Core 4、Slackware 9.1等）。

• 描述在提問前你是怎樣去研究和理解這個問題的。

• 描述在提問前爲肯定問題而採起的診斷步驟。

• 描述最近作過什麼可能相關的硬件或軟件變動。

• 儘量的提供一個能夠重現這個問題的可控環境的方法。

　　儘可能去揣測一個黑客會怎樣反問你，在你提問以前預先將黑客們可能遇到的問題回答一遍。

　　以上幾點中，當你報告的是你認爲可能在代碼中的問題時，給黑客一個能夠重現你的問題的環境尤爲重要。當你這麼作時，你獲得有效的回答的機會和速度都會大大的提高。

　　Simon Tatham 寫過一篇名爲《如何有效的報告 Bug》的出色文章。強力推薦你也讀一讀。

　　話不在多而在精

　　你須要提供精確有內容的信息。這並非要求你簡單的把成堆的出錯代碼或者資料徹底轉錄到你的提問中。若是你有龐大而複雜的測試樣例能重現程序掛掉的情境，儘可能將它剪裁得越小越好。

　　這樣作的用處至少有三點。 第一，表現出你爲簡化問題付出了努力，這能夠使你獲得回答的機會增長； 第二，簡化問題使你更有可能獲得_有用_的答案； 第三，在精煉你的 bug 報告的過程當中，你極可能就本身找到了解決方法或權宜之計。

　　別動輒聲稱找到 Bug

　　當你在使用軟件中遇到問題，除非你很是、_很是_的有根據，不要動輒聲稱找到了 Bug。提示：除非你能提供解決問題的源代碼補丁，或者提供迴歸測試來代表前一版本中行爲不正確，不然你都多半不夠徹底確信。這一樣適用在網頁和文件，若是你（聲稱）發現了文件的Bug，你應該能提供相應位置的修正或替代文件。

　　請記得，還有許多其它使用者沒遇到你發現的問題，不然你在閱讀文件或搜索網頁時就應該發現了（你在抱怨前已經作了這些，是吧？）。這也意味着頗有多是你弄錯了而不是軟件自己有問題。

　　編寫軟件的人老是很是辛苦地使它儘量完美。若是你聲稱找到了 Bug，也就是在質疑他們的能力，即便你是對的，也有可能會冒犯到其中某部分人。當你在標題中嚷嚷着有Bug時，這尤爲嚴重。

　　提問時，即便你私下很是確信已經發現一個真正的 Bug，最好寫得像是_你_作錯了什麼。若是真的有 Bug，你會在回覆中看到這點。這樣作的話，若是真有 Bug，維護者就會向你道歉，這總比你惹惱別人而後欠別人一個道歉要好一點。

　　低三下四不能代替你的功課

　　有些人明白他們不應粗魯或傲慢的提問並要求獲得答覆，但他們選擇另外一個極端 -- 低三下四：我知道我只是個可悲的新手，一個擼瑟，但...。這既令人困擾，也沒有用，尤爲是伴隨着與實際問題含糊不清的描述時更使人反感。

　　別用原始靈長類動物的把戲來浪費你個人時間。取而代之的是，儘量清楚地描述背景條件和你的問題狀況。這比低三下四更好地定位了你的位置。

　　有時網頁論壇會設有專爲新手提問的版面，若是你真的認爲遇到了初學者的問題，到那去就是了，但同樣別那麼低三下四。

　　描述問題症狀而非你的猜想

　　告訴黑客們你認爲問題是怎樣形成的並沒什麼幫助。（若是你的推斷如此有效，還用向別人求助嗎？），所以要確信你原本來本告訴了他們問題的症狀，而不是你的解釋和理論；讓黑客們來推測和診斷。若是你認爲陳述本身的猜想很重要，清楚地說明這只是你的猜想，並描述爲何它們不起做用。

　　蠢問題

我在編譯內核時接連遇到 SIG11 錯誤， 我懷疑某條飛線搭在主板的走線上了，這種狀況應該怎樣檢查最好？

　　聰明問題

個人組裝電腦是 FIC-PA2007 主機板搭載 AMD K6/233 CPU（威盛 Apollo VP2 芯片組）， 256MB Corsair PC133 SDRAM 內存，在編譯內核時，從開機 20 分鐘之後就頻頻產生 SIG11 錯誤， 可是在頭 20 分鐘內從沒發生過相同的問題。從新啓動也沒有用，可是關機一夜就又能工做 20 分鐘。 全部內存都換過了，沒有效果。相關部分的標準編譯記錄以下…。

　　因爲以上這點彷佛讓許多人以爲難以配合，這裏有句話能夠提醒你：全部的診斷專家都來自密蘇里州。 美國國務院的官方座右銘則是：讓我看看（出自國會議員 Willard D. Vandiver 在 1899 年時的講話：我來自一個出產玉米，棉花，牛蒡和民主黨人的國家，滔滔雄辯既不能說服我，也不會讓我滿意。我來自密蘇里州，你必須讓我看看。） 針對診斷者而言，這並非一種懷疑，而只是一種真實而有用的需求，以便讓他們看到的是與你看到的原始證據儘量一致的東西，而不是你的猜想與概括的結論。因此，大方的展現給咱們看吧！

　　按發生時間前後列出問題症狀

　　問題發生前的一系列操做，每每就是對找出問題最有幫助的線索。所以，你的說明裏應該包含你的操做步驟，以及機器和軟件的反應，直到問題發生。在命令行處理的狀況下，提供一段操做記錄（例如運行腳本工具所生成的），並引用相關的若干行（如 20 行）記錄會很是有幫助。

　　若是掛掉的程序有診斷選項（如 -v 的詳述開關），試着選擇這些能在記錄中增長調試信息的選項。記住，多不等於好。試着選取適當的調試級別以便提供有用的信息而不是讓讀者淹沒在垃圾中。

　　若是你的說明很長（如超過四個段落），在開頭簡述問題，接下來再按時間順序詳述會有所幫助。這樣黑客們在讀你的記錄時就知道該注意哪些內容了。

　　描述目標而不是過程

　　若是你想弄清楚如何作某事（而不是報告一個 Bug），在開頭就描述你的目標，而後才陳述重現你所卡住的特定步驟。

　　常常尋求技術幫助的人在心中有個更高層次的目標，而他們在自覺得能達到目標的特定道路上被卡住了，而後跑來問該怎麼走，但沒有意識到這條路自己就有問題。結果要費很大的勁才能搞定。

　　蠢問題

我怎樣才能從某繪圖程序的顏色選擇器中取得十六進制的的 RGB 值？

　　聰明問題

我正試着用替換一幅圖片的色碼（color table）成本身選定的色碼，我如今知道的惟一方法是編輯每一個色碼區塊（table slot）， 但卻沒法從某繪圖程序的顏色選擇器取得十六進制的的 RGB 值。

　　第二種提問法比較聰明，你可能獲得像是建議採用另外一個更合適的工具的回覆。

　　別要求使用私人電郵回覆

　　黑客們認爲問題的解決過程應該公開、透明，此過程當中若是更有經驗的人注意到不完整或者不當之處，最初的回覆纔可以、也應該被糾正。同時，做爲提供幫助者能夠獲得一些獎勵，獎勵就是他的能力和學識被其餘同行看到。

　　當你要求私下回復時，這個過程和獎勵都被停止。別這樣作，讓_回覆者_來決定是否私下回答 -- 若是他真這麼作了，一般是由於他認爲問題編寫太差或者太膚淺，以致於對其它人沒有興趣。

　　這條規則存在一條有限的例外，若是你確信提問可能會引來大量雷同的回覆時，那麼這個神奇的提問句會是向我發電郵，我將爲論壇概括這些回覆。試着將郵件列表或新聞羣組從洪水般的雷同回覆中解救出來是很是有禮貌的 -- 但你必須信守諾言。

　　清楚明確的表達你的問題以及需求

　　漫無邊際的提問是近乎無休無止的時間黑洞。最有可能給你有用答案的人一般也正是最忙的人（他們忙是由於要親自完成大部分工做）。這樣的人對無節制的時間黑洞至關厭惡，因此他們也傾向於厭惡那些漫無邊際的提問。

　　若是你明確表述須要回答者作什麼（如提供指點、發送一段代碼、檢查你的補丁、或是其餘等等），就最有可能獲得有用的答案。由於這會定出一個時間和精力的上限，便於回答者能集中精力來幫你。這麼作很棒。

　　要理解專家們所處的世界，請把專業技能想像爲充裕的資源，而回復的時間則是稀缺的資源。你要求他們奉獻的時間越少，你越有可能從真正專業並且很忙的專家那裏獲得解答。

　　因此，界定一下你的問題，使專家花在辨識你的問題和回答所須要付出的時間減到最少，這技巧對你有用答案至關有幫助 -- 但這技巧一般和簡化問題有所區別。所以，問我想更好的理解 X，能否指點一下哪有好一點說明？一般比問你能解釋一下 X 嗎？更好。若是你的代碼不能運做，一般請別人看看哪裏有問題，比要求別人替你改正要明智得多。

　　詢問有關代碼的問題時

　　別要求他人幫你調試有問題的代碼，不提示一下應該從何入手。張貼幾百行的代碼，而後說一聲：它不能工做會讓你徹底被忽略。只貼幾十行代碼，而後說一句：在第七行之後，我期待它顯示 <x>，但實際出現的是 <y>比較有可能讓你獲得迴應。

　　最有效描述程序問題的方法是提供最精簡的 Bug 展現測試用例（bug-demonstrating test case）。什麼是最精簡的測試用例？那是問題的縮影；一小個程序片斷能恰好展現出程序的異常行爲，而不包含其餘使人分散注意力的內容。怎麼製做最精簡的測試用例？若是你知道哪一行或哪一段代碼會形成異常的行爲，複製下來並加入足夠重現這個情況的代碼（例如，足以讓這段代碼能被編譯/直譯/被應用程序處理）。若是你沒法將問題縮減到一個特定區塊，就複製一份代碼並移除不影響產生問題行爲的部分。總之，測試用例越小越好（查看話不在多而在精一節）。

　　通常而言，要獲得一段至關精簡的測試用例並不太容易，但永遠先嚐試這樣作的是種好習慣。這種方式能夠幫助你瞭解如何自行解決這個問題 —- 並且即便你的嘗試不成功，黑客們也會看到你在嘗試取得答案的過程當中付出了努力，這可讓他們更願意與你合做。

　　若是你只是想讓別人幫忙審查（Review）一下代碼，在信的開頭就要說出來，而且必定要提到你認爲哪一部分特別須要關注以及爲何。

　　別把本身家庭做業的問題貼上來

　　黑客們很擅長分辨哪些問題是家庭做業式的問題；由於咱們中的大多數都曾本身解決這類問題。一樣，這些問題得由_你_來搞定，你會從中學到東西。你能夠要求給點提示，但別要求獲得完整的解決方案。

　　若是你懷疑本身碰到了一個家庭做業式的問題，但仍然沒法解決，試試在使用者羣組，論壇或（最後一招）在項目的使用者郵件列表或論壇中提問。儘管黑客們_會_看出來，但一些有經驗的使用者也許仍會給你一些提示。

　　去掉無心義的提問句

　　避免用無心義的話結束提問，例如有人能幫我嗎？或者這有答案嗎？。

　　首先：若是你對問題的描述不是很好，這樣問更是多此一舉。

　　其次：因爲這樣問是多此一舉，黑客們會很厭煩你 -- 並且一般會用邏輯上正確，但毫無心義的回答來表示他們的蔑視， 例如：沒錯，有人能幫你或者不，沒答案。

　　通常來講，避免用 是或否、對或錯、有或沒有類型的問句，除非你想獲得是或否類型的回答。

　　即便你很急也不要在標題寫緊急

　　這是你的問題，不是咱們的。宣稱緊急極有可能事與願違：大多數黑客會直接刪除無禮和自私地企圖即時引發關注的問題。更嚴重的是，緊急這個字（或是其餘企圖引發關注的標題）一般會被垃圾信過濾器過濾掉 -- 你但願能看到你問題的人可能永遠也看不到。

　　有半個例外的狀況是，若是你是在一些很高調，會使黑客們興奮的地方，也許值得這樣去作。在這種狀況下，若是你有時間壓力，也頗有禮貌地提到這點，人們也許會有興趣回答快一點。

　　固然，這風險很大，由於黑客們興奮的點多半與你的不一樣。譬如從 NASA 國際空間站（International Space Station）發這樣的標題沒有問題，但用自我感受良好的慈善行爲或政治緣由發確定不行。事實上，張貼諸如緊急：幫我救救這個毛絨絨的小海豹！確定讓你被黑客忽略或惹惱他們，即便他們認爲毛絨絨的小海豹很重要。

　　若是你以爲這點很難以想象，最好再把這份指南剩下的內容多讀幾遍，直到你弄懂了再發文。

　　禮多人不怪，並且有時還頗有幫助

　　彬彬有禮，多用請和謝謝您的關注，或謝謝你的關照。讓你們都知道你對他們花時間免費提供幫助心存感激。

　　坦白說，這一點並無比清晰、正確、精準併合法語法和避免使用專用格式重要（也不能取而代之）。黑客們通常寧肯讀有點唐突但技術上鮮明的 Bug 報告，而不是那種有禮但含糊的報告。（若是這點讓你不解，記住咱們是按問題能教給咱們什麼來評價問題的價值的）

　　然而，若是你有一串的問題待解決，客氣一點確定會增長你獲得有用迴應的機會。

　　（咱們注意到，自從本指南發佈後，從資深黑客那裏獲得的惟一嚴重缺陷反饋，就是對預先道謝這一條。一些黑客以爲先謝了意味着過後就不用再感謝任何人的暗示。咱們的建議是要麼先說先謝了，_而後_過後再對回覆者表示感謝，或者換種方式表達感激，譬如用謝謝你的關注或謝謝你的關照。）

　　問題解決後，加個簡短的補充說明

　　問題解決後，向全部幫助過你的人發個說明，讓他們知道問題是怎樣解決的，並再一次向他們表示感謝。若是問題在新聞組或者郵件列表中引發了普遍關注，應該在那裏貼一個說明比較恰當。

　　最理想的方式是向最初提問的話題回覆此消息，並在標題中包含已修正，已解決或其它同等含義的明顯標記。在人來人往的郵件列表裏，一個看見討論串問題 X和問題 X - 已解決的潛在回覆者就明白不用再浪費時間了（除非他我的以爲問題 X的有趣），所以能夠利用此時間去解決其它問題。

　　補充說明沒必要很長或是很深刻；簡單的一句你好，原來是網線出了問題！謝謝你們 – Bill比什麼也不說要來的好。事實上，除非結論真的頗有技術含量，不然簡短可愛的小結比長篇大論更好。說明問題是怎樣解決的，但大可沒必要將解決問題的過程複述一遍。

　　對於有深度的問題，張貼調試記錄的摘要是有幫助的。描述問題的最終狀態，說明是什麼解決了問題，在此_以後_才指明能夠避免的盲點。避免盲點的部分應放在正確的解決方案和其它總結材料以後，而不要將此信息搞成偵探推理小說。列出那些幫助過你的名字，會讓你交到更多朋友。

　　除了有禮貌和有內涵之外，這種類型的補充也有助於他人在郵件列表/新聞羣組/論壇中搜索到真正解決你問題的方案，讓他們也從中受益。

　　至少，這種補充有助於讓每位參與協助的人因問題的解決而從中獲得知足感。若是你本身不是技術專家或者黑客，那就相信咱們，這種感受對於那些你向他們求助的大師或者專家而言，是很是重要的。問題懸而未決會讓人灰心；黑客們渴望看到問題被解決。好人有好報，知足他們的渴望，你會在下次提問時嚐到甜頭。

　　思考一下怎樣才能避免他人未來也遇到相似的問題，自問寫一份文件或加個常見問題（FAQ）會不會有幫助。若是是的話就將它們發給維護者。

　　在黑客中，這種良好的後繼行動實際上比傳統的禮節更爲重要，也是你如何透過善待他人而贏得聲譽的方式，這是很是有價值的資產。