- 文章
- 如何：聰明地提問
2008年4月10日（最後更新：2008年5月9日）
如何：聰明地提問
評分：4.3/5（68票）
Eric Steven Raymond 的作品節選
引言 在程式設計世界裡，你得到的技術問題答案的好壞，與你提問的方式和你開發答案的難度同等重要。
首先要明白的是，程式設計師其實喜歡有挑戰性的問題以及關於這些問題的好且發人深省的提問。如果我們不喜歡，我們就不會在這裡。
程式設計師常常被認為對簡單的問題表現出敵意或傲慢。有時看起來我們對新手和不懂的人會本能地粗魯。但事實並非如此。
提問之前 提問之前，請先做以下事情：
1.嘗試在你打算發帖的論壇的存檔中搜索答案。
2.嘗試在網上搜索答案。
3.嘗試透過閱讀手冊找到答案。
4.嘗試透過閱讀常見問題解答（FAQ）找到答案。
5.嘗試透過檢查或實驗找到答案。
6.嘗試透過詢問一位有經驗的朋友來找到答案。
準備好你的問題。仔細思考。聽起來倉促的問題只會得到倉促的回答，甚至沒有回答。
提問時 仔細選擇你的論壇 在選擇提問的論壇時要謹慎。如果你這樣做，你很可能會被忽略：
•將你的問題釋出到不相關的論壇
•將一個非常基礎的問題釋出到預期會收到高階技術問題的論壇，反之亦然
使用有意義、具體的標題 標題是你吸引合格專家注意力的黃金機會。不要浪費在“請幫幫我”之類的廢話上；不要試圖用你痛苦的深度給我們留下深刻印象；而是用這個空間來簡潔地描述問題。
更普遍地說，想象一下檢視一個問題存檔的索引，只顯示主題行。讓你的主題行充分反映你的問題，以便下一個搜尋類似問題的人能夠順著線索找到答案，而不是再次釋出問題。
使用清晰、語法正確、拼寫準確的語言寫作
清晰、準確地表達你的問題非常重要。花額外的精力來潤色你的語言。不必僵硬或正式，但必須精確。
不要全部使用大寫字母 typing in all caps；這會被解讀為喊叫，並被認為是不禮貌的。
如果你寫得像個半文盲的笨蛋，你很可能會被忽視。所以不要使用即時通訊的快捷方式。
關於你的問題要精確且資訊豐富 •仔細清晰地描述你的問題的症狀。
•描述問題發生的執行環境（機器、作業系統、應用程式等）。
•描述你在提問之前為理解問題所做的研究。
•描述你在提問之前為確定問題所在而採取的診斷步驟。
盡你所能預測回應者會問的問題，並在你的求助請求中預先回答它們。
數量不等於精確性 你需要精確且資訊豐富。簡單地將大量程式碼或資料轉儲到幫助請求中並不能達到這個目的。如果你有一個大的、複雜的測試用例導致程式崩潰，儘量將其修剪並使其儘可能小。
這至少有三個原因是有用的。一：你投入精力簡化問題，更有可能得到回答；二：簡化問題更有可能得到有用的回答；三：在完善你的 bug 報告的過程中，你可能會自己開發出一個修復程式或解決方法。
描述問題的症狀，而不是你的猜測 告訴程式設計師你認為是什麼導致了你的問題是沒有用的。所以，請確保你告訴他們的是錯誤的原始症狀，而不是你的解釋和理論。讓他們進行解釋和診斷。如果你覺得陳述你的猜測很重要，請清楚地將其標記為猜測，並說明為什麼那個答案對你不起作用。
描述目標，而不是步驟
如果你想弄清楚如何做某事，首先要描述目標。然後才描述你在此過程中遇到的具體阻礙。
通常，需要技術幫助的人心裡都有一個高層次的目標，但被他們認為是通往目標的特定路徑所困擾。他們來尋求步驟方面的幫助，但沒有意識到這條路徑是錯誤的。要克服這一點可能需要付出巨大的努力。
明確你的問題 開放式問題往往被視為耗時過多的開放式問題。最有可能給你有用答案的人也是最忙的人（僅僅因為他們自己承擔了最多的工作）。這樣的人對耗時過多的開放式問題很敏感，因此他們傾向於對開放式問題很敏感。
如果你明確你想讓回覆者做什麼（提供線索、傳送程式碼等），你更有可能得到有用的回覆。這將集中他們的精力，並間接限制回覆者必須為你提供幫助的時間和精力。
提問程式碼時 不要要求別人除錯你的損壞程式碼，卻不給任何關於他們應該搜尋什麼問題的提示。釋出幾百行程式碼，然後說“它不起作用”，你會被忽視。釋出十幾行程式碼，說“在第 7 行之後，我期望看到，但發生了 ”，這樣得到回應的可能性更大。
如果你只是想進行程式碼審查，請提前說明，並務必提及你認為可能需要特別審查的領域以及原因。
不要釋出家庭作業問題 程式設計師很擅長識別家庭作業問題；我們大多數人都做過。這些問題是為了讓你自己解決，以便你從中學習。可以尋求提示，但不能尋求完整的解決方案。
跟進一個關於解決方案的簡短說明 問題解決後，向所有幫助過你的人傳送一條訊息；讓他們知道結果如何，並再次感謝他們的幫助。
你的後續不需要冗長而複雜；一句簡單的“你好，原來是網路線纜出了問題！謝謝大家。- Bill”總比什麼都沒有好。
事實上，除非解決方案具有真正的技術深度，否則一個簡短而甜蜜的總結比冗長的論文更好。說明解決了問題的操作，但你不需要重述整個故障排除過程。
除了禮貌和資訊豐富之外，這種後續行動還能幫助其他搜尋郵件列表/新聞組/論壇存檔的人確切地知道哪個解決方案幫助了你，從而可能幫助到他們。
最後但同樣重要的是，這種後續行動有助於所有幫助過的人對問題有一個令人滿意的了結感。那些最終不了了之的問題敘述令人沮喪；程式設計師渴望看到它們得到解決。你透過撓癢癢而贏得的良好意願，下次提問時會對你非常有幫助。
如何解讀答案 如果你不明白…… 如果你不明白答案，不要立即反彈要求澄清。使用你用來嘗試回答最初問題相同的工具（手冊、FAQ、網路、有經驗的朋友）來理解答案。然後，如果你仍然需要澄清，請展示你學到的東西。
如果你得不到答案 如果你得不到答案，請不要認為我們無能為力是針對你個人的。有時，被問及的群組的成員可能根本不知道答案。沒有回應不等於被忽視，儘管從外面很難區分。
總的來說，簡單地重複釋出你的問題是個壞主意。這會被視為毫無意義的煩擾。要有耐心：擁有你答案的人可能在不同的時區，還在睡覺。或者，你的問題從一開始就沒有組織好。
如何以有幫助的方式回答問題
要溫和。 與問題相關的壓力會使人顯得粗魯或愚蠢，即使他們不是。
回覆初犯者私下進行。 對於可能犯了無心之失的人，沒有必要公開羞辱。一個真正的新手可能不知道如何搜尋存檔，或者 FAQ 儲存在哪裡或張貼在哪裡。
如果你不確定，就說出來！ 一個錯誤的但聽起來權威的答案比沒有答案還要糟糕。不要僅僅因為聽起來像專家很有趣而將任何人引向錯誤的道路。保持謙虛和誠實；為提問者和你的同行樹立一個好榜樣。
如果你幫不了忙，就不要妨礙。 不要拿可能破壞使用者設定的程式開玩笑——那個可憐的傢伙可能會把這些當作指示。
提出探索性問題以獲取更多細節。 如果你在這方面很擅長，提問者會學到東西——你可能也會。試著將壞問題變成好問題；記住，我們曾經都是新手。
雖然有時對懶惰的傢伙回覆“去讀手冊”（RTFM）是可以理解的，但指向文件（即使只是建議去谷歌搜尋關鍵詞）會更好。
如果你要回答問題，就要提供有價值的資訊。 當有人使用錯誤的工具或方法時，不要建議蹩腳的變通方法。推薦好的工具。重新組織問題。
引言 在程式設計世界裡，你得到的技術問題答案的好壞，與你提問的方式和你開發答案的難度同等重要。
首先要明白的是，程式設計師其實喜歡有挑戰性的問題以及關於這些問題的好且發人深省的提問。如果我們不喜歡，我們就不會在這裡。
程式設計師常常被認為對簡單的問題表現出敵意或傲慢。有時看起來我們對新手和不懂的人會本能地粗魯。但事實並非如此。
提問之前 提問之前，請先做以下事情：
1.嘗試在你打算發帖的論壇的存檔中搜索答案。
2.嘗試在網上搜索答案。
3.嘗試透過閱讀手冊找到答案。
4.嘗試透過閱讀常見問題解答（FAQ）找到答案。
5.嘗試透過檢查或實驗找到答案。
6.嘗試透過詢問一位有經驗的朋友來找到答案。
準備好你的問題。仔細思考。聽起來倉促的問題只會得到倉促的回答，甚至沒有回答。
提問時 仔細選擇你的論壇 在選擇提問的論壇時要謹慎。如果你這樣做，你很可能會被忽略：
•將你的問題釋出到不相關的論壇
•將一個非常基礎的問題釋出到預期會收到高階技術問題的論壇，反之亦然
使用有意義、具體的標題 標題是你吸引合格專家注意力的黃金機會。不要浪費在“請幫幫我”之類的廢話上；不要試圖用你痛苦的深度給我們留下深刻印象；而是用這個空間來簡潔地描述問題。
更普遍地說，想象一下檢視一個問題存檔的索引，只顯示主題行。讓你的主題行充分反映你的問題，以便下一個搜尋類似問題的人能夠順著線索找到答案，而不是再次釋出問題。
使用清晰、語法正確、拼寫準確的語言寫作
清晰、準確地表達你的問題非常重要。花額外的精力來潤色你的語言。不必僵硬或正式，但必須精確。
不要全部使用大寫字母 typing in all caps；這會被解讀為喊叫，並被認為是不禮貌的。
如果你寫得像個半文盲的笨蛋，你很可能會被忽視。所以不要使用即時通訊的快捷方式。
關於你的問題要精確且資訊豐富 •仔細清晰地描述你的問題的症狀。
•描述問題發生的執行環境（機器、作業系統、應用程式等）。
•描述你在提問之前為理解問題所做的研究。
•描述你在提問之前為確定問題所在而採取的診斷步驟。
盡你所能預測回應者會問的問題，並在你的求助請求中預先回答它們。
數量不等於精確性 你需要精確且資訊豐富。簡單地將大量程式碼或資料轉儲到幫助請求中並不能達到這個目的。如果你有一個大的、複雜的測試用例導致程式崩潰，儘量將其修剪並使其儘可能小。
這至少有三個原因是有用的。一：你投入精力簡化問題，更有可能得到回答；二：簡化問題更有可能得到有用的回答；三：在完善你的 bug 報告的過程中，你可能會自己開發出一個修復程式或解決方法。
描述問題的症狀，而不是你的猜測 告訴程式設計師你認為是什麼導致了你的問題是沒有用的。所以，請確保你告訴他們的是錯誤的原始症狀，而不是你的解釋和理論。讓他們進行解釋和診斷。如果你覺得陳述你的猜測很重要，請清楚地將其標記為猜測，並說明為什麼那個答案對你不起作用。
描述目標，而不是步驟
如果你想弄清楚如何做某事，首先要描述目標。然後才描述你在此過程中遇到的具體阻礙。
通常，需要技術幫助的人心裡都有一個高層次的目標，但被他們認為是通往目標的特定路徑所困擾。他們來尋求步驟方面的幫助，但沒有意識到這條路徑是錯誤的。要克服這一點可能需要付出巨大的努力。
明確你的問題 開放式問題往往被視為耗時過多的開放式問題。最有可能給你有用答案的人也是最忙的人（僅僅因為他們自己承擔了最多的工作）。這樣的人對耗時過多的開放式問題很敏感，因此他們傾向於對開放式問題很敏感。
如果你明確你想讓回覆者做什麼（提供線索、傳送程式碼等），你更有可能得到有用的回覆。這將集中他們的精力，並間接限制回覆者必須為你提供幫助的時間和精力。
提問程式碼時 不要要求別人除錯你的損壞程式碼，卻不給任何關於他們應該搜尋什麼問題的提示。釋出幾百行程式碼，然後說“它不起作用”，你會被忽視。釋出十幾行程式碼，說“在第 7 行之後，我期望看到
如果你只是想進行程式碼審查，請提前說明，並務必提及你認為可能需要特別審查的領域以及原因。
不要釋出家庭作業問題 程式設計師很擅長識別家庭作業問題；我們大多數人都做過。這些問題是為了讓你自己解決，以便你從中學習。可以尋求提示，但不能尋求完整的解決方案。
跟進一個關於解決方案的簡短說明 問題解決後，向所有幫助過你的人傳送一條訊息；讓他們知道結果如何，並再次感謝他們的幫助。
你的後續不需要冗長而複雜；一句簡單的“你好，原來是網路線纜出了問題！謝謝大家。- Bill”總比什麼都沒有好。
事實上，除非解決方案具有真正的技術深度，否則一個簡短而甜蜜的總結比冗長的論文更好。說明解決了問題的操作，但你不需要重述整個故障排除過程。
除了禮貌和資訊豐富之外，這種後續行動還能幫助其他搜尋郵件列表/新聞組/論壇存檔的人確切地知道哪個解決方案幫助了你，從而可能幫助到他們。
最後但同樣重要的是，這種後續行動有助於所有幫助過的人對問題有一個令人滿意的了結感。那些最終不了了之的問題敘述令人沮喪；程式設計師渴望看到它們得到解決。你透過撓癢癢而贏得的良好意願，下次提問時會對你非常有幫助。
如何解讀答案 如果你不明白…… 如果你不明白答案，不要立即反彈要求澄清。使用你用來嘗試回答最初問題相同的工具（手冊、FAQ、網路、有經驗的朋友）來理解答案。然後，如果你仍然需要澄清，請展示你學到的東西。
如果你得不到答案 如果你得不到答案，請不要認為我們無能為力是針對你個人的。有時，被問及的群組的成員可能根本不知道答案。沒有回應不等於被忽視，儘管從外面很難區分。
總的來說，簡單地重複釋出你的問題是個壞主意。這會被視為毫無意義的煩擾。要有耐心：擁有你答案的人可能在不同的時區，還在睡覺。或者，你的問題從一開始就沒有組織好。
如何以有幫助的方式回答問題
要溫和。 與問題相關的壓力會使人顯得粗魯或愚蠢，即使他們不是。
回覆初犯者私下進行。 對於可能犯了無心之失的人，沒有必要公開羞辱。一個真正的新手可能不知道如何搜尋存檔，或者 FAQ 儲存在哪裡或張貼在哪裡。
如果你不確定，就說出來！ 一個錯誤的但聽起來權威的答案比沒有答案還要糟糕。不要僅僅因為聽起來像專家很有趣而將任何人引向錯誤的道路。保持謙虛和誠實；為提問者和你的同行樹立一個好榜樣。
如果你幫不了忙，就不要妨礙。 不要拿可能破壞使用者設定的程式開玩笑——那個可憐的傢伙可能會把這些當作指示。
提出探索性問題以獲取更多細節。 如果你在這方面很擅長，提問者會學到東西——你可能也會。試著將壞問題變成好問題；記住，我們曾經都是新手。
雖然有時對懶惰的傢伙回覆“去讀手冊”（RTFM）是可以理解的，但指向文件（即使只是建議去谷歌搜尋關鍵詞）會更好。
如果你要回答問題，就要提供有價值的資訊。 當有人使用錯誤的工具或方法時，不要建議蹩腳的變通方法。推薦好的工具。重新組織問題。