[ 分享] 提問的智慧

[轉貼]提問的智慧

Copyright (C) 2001 by Eric S. Raymond 
中文版Copyleft 2001 by DHGrand(nOBODY/Ginux) 

繁體版：http://phorum.vbird.org/viewtopic.php?t=96
英文版：http://www.tuxedo.org/~esr/faqs/smart-questions.html
感謝Eric的耐心指點和贊成，本文才得以完成併發布，
本指南英文版版權爲Eric Steven Raymond全部，
中文版版權由DHGrand[nOBODY/Ginux]全部。

在黑客世界，當提出一個技術問題時，你能獲得怎樣的回答？
這取決於挖出答案的難度，一樣取決於你提問的方法。
本指南旨在幫助你提升發問技巧，以獲取你最想要的答案。

首先你必須明白，黑客們只偏心艱鉅的任務，或者能激發他們思惟的好問題。
如若否則，咱們還來幹嘛？若是你有值得咱們反覆咀嚼玩味的好問題，
咱們自會對你感激涕零。好問題是激勵，是厚禮，能夠提升咱們的理解力，
並且一般會暴露咱們之前從沒意識到或者思考過的問題。
對黑客而言，「問得好！」是發自心裏的大力稱讚。

儘管黑客們有蔑視簡單問題和不友善的壞名聲，有時看起來彷佛咱們對新手，
對知識貧乏者懷有敵意，但其實不是那樣的。

咱們不想掩飾對這樣一些人的蔑視--他們不肯思考，
或者在發問前不去完成他們應該作的事。
這種人只會謀殺時間--他們只願索取，從不付出，無故消耗咱們的時間，
而咱們本能夠把時間用在更有趣的問題或者更值得回答的人身上。
咱們稱這樣的人爲「失敗者」（因爲歷史緣由，咱們有時把它拼做「lusers」）。

咱們在很大程度上屬於志願者，從繁忙的生活中抽出時間來解惑答疑，
並且時常被提問淹沒。因此咱們無情的濾掉一些話題，
特別是拋棄那些看起來象失敗者的傢伙，以便更高效的利用時間來回答勝利者的問題。

若是你以爲咱們過於傲慢的態度讓你不爽，讓你委屈，不妨設身處地想一想。
咱們並無要求你向咱們屈服--事實上，咱們中的大多數人最喜歡公平交易不過了，
只要你付出小小努力來知足最起碼的要求，咱們就會歡迎你加入到咱們的文化中來?但讓咱們幫助那些不肯意幫助本身的人是沒有意義的。

若是你不能接受這種「歧視」，咱們建議你花點錢找家商業公司籤個術支援協議得了，
別向黑客乞求若是你決定向咱們求助，固然不但願被視爲失敗者，
更不肯成爲失敗者中的一員。馬上獲得有效答案的最好方法，就是象勝利者那樣提問
——聰明、自信、有解決問題的思路，只是偶爾在特定的問題上須要得到一點幫助。

（歡迎對本指南提出改進意見。任何建議請E-mail至esr@thyrsus.com，
然而請注意，本文並不是網路禮節的通用指南，我一般會拒絕無助於在技術論壇
獲得有用答案的建議。 ） （固然，若是你寫中文，最好仍是寄DHGrand@hotmail.com;-）

=提問以前=

在經過電郵、新聞組或者聊天室提出技術問題前，檢查你有沒有作到：

1. 通讀手冊，試着本身找答案。
2. 在FAQ?找答案（一份維護得好的FAQ能夠一應俱全:）。
3. 在網上搜索（我的推薦google~~~）。
4. 向你身邊精於此道的朋友打聽。

當你提出問題的時候，首先要說明在此以前你幹了些什麼；
這將有助於樹立你的形象：你不是一個妄圖坐享其成的乞討者，不肯浪費別人的時間。
若是提問者能從答案中學到東西，咱們更樂於回答他的問題。

周全的思考，準備好你的問題，草率的發問只能獲得草率的回答，
或者根本得不到任何答案。越表現出在尋求幫助前爲解決問題付出的努力，
你越能獲得實質性的幫助。

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

決不要自覺得夠資格獲得答案，你沒這種資格。畢竟你沒有爲這種服務支付任何報酬。
你要本身去「掙」回一個答案，靠提出一個有內涵的，有趣的，
有思惟激勵做用的問題--一個對社區的經驗有潛在貢獻的問題，
而不只僅是被動的從他人處索要知識--去掙到這個答案。

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

=怎樣提問=

1. -謹慎選擇論壇
   當心選擇提問的場合。若是象下面描述的那樣，你極可能被忽略掉或者被看做失敗者：
   1. 在風馬牛不相及的論壇貼出你的問題
   2. 在探討高級技巧的論壇張貼很是初級的問題；反之亦然
   3. 在太多的不一樣新聞組交叉張貼
2. -用辭貼切，語法正確，拼寫無誤
   咱們從經驗中發現，粗心的寫做者一般也是馬虎的思考者（我敢打包票）。
   回答粗枝大葉者的問題很不值得，咱們寧願把時間耗在別處。
   
   正確的拼寫，標點符號和大小寫很重要。
   更通常的說，若是你的提問寫得象個半文盲，你頗有可能被忽視。
   
   若是你在使用非母語的論壇提問，你能夠犯點拼寫和語法上的小錯
   --但決不能在思考上馬虎（沒錯，咱們能弄清二者的分別）
3. -使用含義豐富，描述準確的標題
   在郵件列表或者新聞組中，大約50字之內的主題標題是抓住資深專家注意力的黃金時機。
   別用喋喋不休的「幫幫忙」（更別說「救命啊！！！！！」這樣讓人反感的話）
   來浪費這個機會。不要妄想用你的痛苦程度來打動咱們，別用空格代替問題的描述，
   哪怕是極其簡短的描述。
   
   蠢問題：救命啊！個人膝上機不能正常顯示了！
   聰明問題： XFree86 4.1下滑鼠遊標變形，Fooware MV1005的顯示晶片。
   
   若是你在回覆中提出問題，記得要修改內容標題，代表?面有一個問題。
   一個看起來象「Re：測試」或者「Re：新bug」的問題很難引發足夠重視。
   另外，引用並刪減前文的內容，給新來的讀者留下線索。
4. - 精確描述，信息量大
   1. 謹慎明確的描述症狀。
   2. 提供問題發生的環境（機器配置、做業系統、應用程式以及別的什麼）。
   3. 說明你在提問前是怎樣去研究和理解這個問題的。
   4. 說明你在提問前採起了什麼步驟去解決它。
   5. 羅列最近作過什麼可能有影響的硬體、軟體變動。
   儘可能想像一個黑客會怎樣反問你，在提問的時候預先給他答案。
   
   Simon Tatham寫過一篇名爲《如何有效的報告Bug》的出色短文。強力推薦你也讀一讀。
5. -話不在多
   你須要提供精確有效的資訊。這並非要求你簡單的把成噸的出錯代碼或者資料
   徹底轉儲摘錄到你的提問中。若是你有龐大而複雜的測試條件，
   儘可能把它剪裁得越小越好。這樣作的用處至少有三點。
   第一，表現出你爲簡化問題付出了努力，這可使你獲得回答的機會增長；
   第二，簡化問題使你獲得有用答案的機會增長；
   第三，在提煉你的bug報告的過
6. -只說症狀，不說猜測
   告訴黑客們你認爲問題是怎樣引發的沒什麼幫助。
   （若是你的推斷如此有效，還用向別人求助嗎？），
   所以要確信你原本來本告訴了他們問題的症狀，不要加進你本身的理解和推論。
   讓黑客們來診斷吧。
   
   蠢問題：我在內核編譯中一次又一次遇到SIG11錯誤，
   我懷疑某條飛線搭在主板的走線上了，這種狀況應該怎樣檢查最好？
   聰明問題：我自制的一套K6/233系統，主板是FIC-PA2007 （VIA Apollo VP2晶片組），
   256MB Corsair PC133 SDRAM，在內核編譯中頻頻產生SIG11錯誤，
   從開機20分鐘之後就有這種狀況，開機前20分鐘內從沒發生過。
   重啓也沒有用，可是關機一夜就又能工做20分鐘。全部記憶體都換過了，沒有效果。
   相關部分的典型編譯記錄以下...。
7. -按時間順序列出症狀
   對找出問題最有幫助的線索，每每就是問題發生前的一系列操做，
   所以，你的說明應該包含操做步驟，以及電腦的反應，直到問題產生。
   
   若是你的說明很長（超過四個段落），在開頭簡述問題會有所幫助，
   接下來按時間順序詳述。這樣黑客們就知道該在你的說明中找什麼。
8. -明白你想問什麼
   漫無邊際的提問近乎無休無止的時間黑洞。最能給你有用答案的人也正是最忙的人
   （他們忙是由於要親自完成大部分工做）。這樣的人對無節制的時間黑洞不太感冒，
   所以也能夠說他們對漫無邊際的提問不大感冒。
   
   若是你明確表述須要回答者作什麼（提供建議，發送一段代碼，檢查你的補丁或是別的）
   ，就最有可能獲得有用的答案。
   這會定出一個時間和精力的上限，便於回答者集中精力來幫你
   A這很湊效。要理解專家們生活的世界，要把專業技能想像爲充裕的資源，
   而回復的時間則是貧乏的資源。解決你的問題須要的時間越少，
   越能從忙碌的專家口中掏出答案。
   
   所以，優化問題的結構，儘可能減小專家們解決它所須要的時間，
   會有很大的幫助--這一般和簡化問題有所區別。
   所以，問「我想更好的理解X，能給點提示嗎？」一般比問「你能解釋一下X嗎？更好。
   若是你的代碼不能工做，問問它有什麼地方不對，比要求別人替你修改要明智得多。
9. -別問應該本身解決的問題
   黑客們老是善於分辨哪些問題應該由你本身解決；由於咱們中的大多數都曾本身解決
   這類問題。一樣，這些問題得由你來搞定，你會從中學到東西。
   你能夠要求給點提示，但別要求獲得完整的解決方案。
10. -去除無心義的疑問
    別用無心義的話結束提問，例如「有人能幫我嗎？」或者「有答案嗎？」。
    首先：若是你對問題的描述不很合適，這樣問更是多此一舉。
    其次：因爲這樣問是多此一舉，黑客們會很厭煩你--並且一般會用邏輯上正確的回答
    來表示他們的蔑視，例如：「沒錯，有人能幫你」或者「不，沒答案」。
11. -謙遜絕沒有害處，並且常幫大忙
    彬彬有禮，多用「請」和「先道個謝了」。
    讓你們都知道你對他們花費時間義務提供幫助心存感激。
    然而，若是你有不少問題沒法解決，禮貌將會增長你獲得有用答案的機會。
    
    （咱們注意到，自從本指南發佈後，從資深黑客處獲得的惟一嚴重缺陷反饋，
    就是對預先道謝這一條。一些黑客以爲「先謝了」的言外之意是事後就不會再感謝
    任何人了。咱們的建議是：都道謝。）
12. -問題解決後，加個簡短說明
    問題解決後，向全部幫助過你的人發個說明，讓他們知道問題是怎樣解決的，
    並再一次向他們表示感謝。若是問題在新聞組或者郵件列表中引發了普遍關注，
    應該在那?貼一個補充說明
    。補充說明沒必要很長或是很深刻；簡單的一句「你好，原來是網線出了問題！
    謝謝你們--Bill」比什麼也不說要強。事實上，除非結論真的頗有技術含量，
    不然簡短可愛的小結比長篇學
    術論文更好。說明問題是怎樣解決的，但大可沒必要將解決問題的過程複述一遍。
    除了表示禮貌和反饋資訊之外，這種補充有助於他人在郵件列表/新聞組/論壇中搜索
    對你有過幫助的完整
    解決方案，這可能對他們也頗有用。最後（至少？），
    這種補充有助於全部提供過幫助的人從中獲得知足感。
    若是你本身不是老手或者黑客，那就相信咱們，這種感受對於那些你向他們
    求助的導師或者專家而言，是很是重要的。問題久拖未決會讓人灰心；
    黑客們渴望看到問題被解決。好人有好報，知足他們的渴望，
    你會在下次貼出新問題時嚐到甜頭。
13. -仍是不懂
    若是你不是很理解答案，別馬上要求對方解釋。
    象你之前試着本身解決問題時那樣（利用手冊，FAQ，網路，身邊的高手），
    去理解它。若是你真的須要對方解釋，記得表現出你已經學
    鴗F點什麼。比方說，若是我回答你：「看來彷佛是zEntry被阻塞了；
    你應該先清除它。」，而後：一個很糟的後續問題：「zEntry是什麼？」 
    聰明的問法應該是這樣：「哦~~~我看過幫助了可是隻有-z和-p兩個參數中
    提到了zEntry並且還都沒有清楚的解釋:<你是指這兩個中的哪個嗎？
    仍是我看漏了什麼？ 」

=三思然後問=

如下是幾個經典蠢問題，以及黑客在拒絕回答時的心中所想：

問題：我能在哪找到X程式？
問題：個人程式/配置/SQL申明沒有用
問題：個人Windows有問題，你能幫我嗎？
問題：我在安裝Linux（或者X）時有問題，你能幫我嗎？
問題：我怎麼才能破解root賬號/竊取OP特權/讀別人的郵件呢？

提問：我能在哪找到X程式？
回答：就在我找到它的地方啊蠢貨--搜索引擎的那一頭。天?！還有人不會用Google嗎？

提問：個人程式（配置、SQL申明）沒有用
回答：這不算是問題吧，我對找出你的真正問題沒興趣--若是要我問你二十個問題
才找得出來的話--我有更有意思的事要作呢。

在看到這類問題的時候，個人反應一般不外以下三種

1. 你還有什麼要補充的嗎？
2. 真糟糕，但願你能搞定。
3. 這跟我有什麼鳥相關？

提問：個人Windows有問題，你能幫我嗎？
回答：能啊，扔掉萎軟的垃圾，換Linux吧。

提問：我在安裝Linux（或者X）時有問題，你能幫我嗎？
回答：不能，我只有親自在你的電腦上動手才能找到毛病。
仍是去找你當地的Linux用戶組尋求手把手的指導吧（你能在這兒找到用戶組的清單）。

提問：我怎麼才能破解root賬號/竊取OP特權/讀別人的郵件呢？
回答：想要這樣作，說明你是個卑鄙小人；想找個黑客幫你，說明你是個白癡！

=好問題，壞問題=

最後，我舉一些例子來講明，怎樣聰明的提問；
同一個問題的兩種問法被放在一塊兒，一種是愚蠢的，另外一種纔是明智的。

蠢問題：我能夠在哪兒找到關於Foonly Flurbamatic的資料？
//這種問法無非想獲得「STFW」這樣的回答。

聰明問題：我用Google搜索過「Foonly Flurbamatic 2600」，
可是沒找到有用的結果。誰知道上哪兒去找對這種設備編程的資料？
//這個問題已經STFW過了，看起來他真的遇到了麻煩。

蠢問題：我從FOO項目找來的源碼無法編譯。它怎麼這麼爛？
//他以爲都是別人的錯，這個傲慢自大的傢伙

聰明問題：FOO專案代碼在Nulix 6.2版下沒法編譯經過。
我讀過了FAQ，但?面沒有提到跟Nulix有關的問題。
這是我編譯過程的記錄，我有什麼作得不對的地方嗎？
//他講明瞭環境，也讀過了FAQ，還指明瞭錯誤，
而且他沒有把問題的責任推到別人頭上，這個傢伙值得留意。

蠢問題：個人主板有問題了，誰來幫我？
//普通黑客對這類問題的回答一般是：「好的，還要幫你拍拍背和換尿布嗎？」 
，而後按下刪除鍵。

聰明問題：我在S2464主板上試過了X、Y和Z，但沒什麼做用，
我又試了A、B和C。請注意當我嘗試C時的奇怪現象。顯然邊帶傳輸中出現了收縮，
但結果出人意料。在多處理器主板上引發邊帶泄漏的一般緣由是什麼？
誰有好主意接下來我該作些什麼測試才能找出問題？
//這個傢伙，從另外一個角度來看，值得去回答他。他表現出瞭解決問題的能力，
而不是坐等天上掉答案。

在最後一個問題中，注意「告訴我答案」和「給我啓示，指出我還應該作什麼診斷工做」 
之間微妙而又重要的區別。
事實上，後一個問題源自於2001年8月在Linux內核郵件列表上的一個真實的提問。
我（Eric）就是那個提出問題的人。我在Tyan S2464主板上觀察到了這種沒法解釋的
鎖定現象，列表成員們提供瞭解決那一問題的重要資訊。

經過個人提問方法，我給了你們值得玩味的東西；我讓人們很容易參與而且被吸引進來。
我顯示了本身具有和他們同等的能力，邀請他們與我共同探討。
我告訴他們我所走過的彎路，以免他們再浪費時間，這是一種對他人時間價值的尊重。
後來，當我向每一個人表示感謝，而且讚揚這套程式（指郵件列表中的討論
--譯者注）運做得很是出色的時候，一個Linux內核?件列（lkml）成員表示，問題獲得解決並不是因爲我是這個列表中的「名人」，
而是由於我用了正確的方式來提問。
咱們黑客從某種角度來講是擁有豐富知識但缺少人情味的傢伙；我相信
他是對的，若是我象個乞討者那樣提問，不論我是誰，必定會惹惱某些人
或者被他們忽視。他建議我記下這件事，給編寫這個指南的人一些指導。

=找不到答案怎麼辦=

若是仍得不到答案，請不要覺得咱們以爲沒法幫助你。
有時只是看到你問題的人不知道答案罷了。沒有迴應不表明你被忽視，
雖然不能否認這種差異很難區分。

總的說來，簡單的重複張貼問題是個很糟的想法。這將被視爲無心義的喧鬧。

你能夠經過其餘渠道得到幫助，這些渠道一般更適合初學者的須要。
有許多網上的以及本地的用戶組，由狂熱的軟體愛好者
（即便他們可能從沒親自寫過任何軟體）組成。一般人們組建
這樣的團體來互相幫助並幫助新手。

另外，你能夠向不少商業公司尋求幫助，不論公司大仍是小
（Red Hat和LinuxCare就是兩個最多見的例子）。
別爲要付費才能得到幫助而感到沮喪！畢竟，假使你的汽車發動機汽缸密
封圈爆掉了--徹底可能如此--你還得把它送到修車鋪，而且爲維修付費。
就算軟體沒花費你一分錢，你也不能強求技術支援老是免費的。

對大衆化的軟體，就象Linux之類而言，每一個開發者至少會有上萬名用戶。
根本不可能由一我的來處理來自上萬名用戶的求助電話。
要知道，即便你要爲幫助付費，同你必須購買同類軟體相比，
你所付出的也是微不足道的（一般封閉源代碼軟體的技術支援費用比開放源代碼軟體
要高得多，且內容也不那麼豐富）。

RTFM和STFW：別煩我啦

有一個古老而神聖的傳統：若是你收到「RTFM （Read The Fucking Manual）」的
回覆，回答者認爲你應該去讀TMD手冊。固然，基本上他是對的，你應該讀一讀。

RTFM有一個年輕的親戚。若是答案是「STFW （Search The Fucking Web）」，回
答者認爲你應該到TMD的網上去搜索。基本上，他也是對的，你就去找吧。

一般，用這兩句之一回答你的人會給你一份包含你須要內容的手冊或者一個網址，
並且他們打這些字的時候正在閱讀着。
這些答覆意味着回答者認爲
(1).你須要的資訊很是容易得到；
(2).你本身去搜索這些資訊比灌給你能讓你學到更多。

別爲這個而不爽；依照黑客的標準，他沒有對你的要求視而不見，已經能大體能表
示對你的關注。你應該對他祖母般的慈祥表示感謝。
-