- 文章
- 提問的智慧
2009年10月9日
提問的智慧
評分: 4.2/5 (40 票)
Eric Steven Raymond 作品的縮寫版
首先要理解的是，程式設計師實際上喜歡難題和關於它們的好問題，發人深省的問題。 如果我們不喜歡，我們就不會在這裡
程式設計師以對簡單問題表現出敵意或傲慢而聞名。有時看起來我們是對菜鳥和無知者的一種本能性的粗魯。 但這並非完全正確。
準備好你的問題。仔細思考。草率的問題只會得到草率的答案，或者根本沒有答案。
使用有意義的、具體的標題 標題是你吸引合格專家注意力的黃金機會。不要把它浪費在諸如“請幫幫我”之類的閒聊上。不要試圖用你的痛苦程度來打動我們；而是用這個空間來寫一個超級簡潔的問題描述。
更一般地說，想象一下檢視問題存檔的索引，只顯示主題行。讓你的主題行充分反映你的問題，以便下一個搜尋與你類似問題的傢伙能夠跟隨該執行緒找到答案，而不是再次釋出問題。
用清晰的、符合語法的、拼寫正確的語言寫作
清晰地表達你的問題非常重要。花額外的精力來潤色你的語言。不一定要生硬或正式。但必須精確。
不要使用全部大寫字母；這會被解讀為喊叫，並且被認為是不禮貌的。
如果你像一個半文盲的笨蛋一樣寫作，你很可能會被忽略。所以不要使用即時通訊的快捷方式。
精確而翔實地描述你的問題
盡你所能預測回答者會提出的問題，並在你的求助請求中提前回答它們。
數量並不等於精確 你需要精確而翔實。簡單地將大量的程式碼或資料轉儲到幫助請求中並不能達到這個目的。如果你有一個龐大而複雜的測試用例，它正在破壞程式，請嘗試修剪它，並使其儘可能小。
這至少有三個原因很有用。一：投入精力簡化問題更容易獲得答案。二：簡化問題更容易獲得有用的答案。三：在改進錯誤報告的過程中，你可能會自己開發出修復或解決方法。
描述問題的症狀，而不是你的猜測 告訴程式設計師你認為是什麼導致了你的問題沒有用。所以，確保你告訴他們出錯的原始症狀，而不是你的解釋和理論。讓他們進行解釋和診斷。如果你覺得說明你的猜測很重要，請清楚地將其標記為猜測，並描述為什麼該答案對你不起作用。
描述目標，而不是步驟
如果你試圖找出如何做某事，請首先描述目標。然後才描述你被阻止的特定步驟。
通常，需要技術幫助的人腦海中有一個高層次的目標，並且卡在他們認為通往該目標的特定路徑上。他們來尋求該步驟的幫助，但沒有意識到該路徑是錯誤的。克服這一點可能需要大量的努力。
明確你的問題 開放式問題往往被認為是開放式的時間消耗。最有可能給你有用答案的人也是最忙的人（僅僅因為他們承擔了最多的工作）。這樣的人對開放式的時間消耗過敏，因此他們往往對開放式問題過敏。
如果你明確希望回答者做什麼（提供指標，傳送程式碼，...），你更有可能得到有用的回應。這將集中他們的精力，並隱含地為回答者必須分配的幫助你的時間和精力設定上限。
如果你只是想要程式碼審查，請提前說明，並務必提及你認為哪些領域可能特別需要審查以及原因。
你的跟進不必冗長而複雜；一個簡單的 “你好，這是一個失敗的網路電纜！謝謝大家。 - 比爾” 會好過什麼都沒有。
事實上，除非該解決方案具有真正的技術深度，否則簡短而簡潔的總結比冗長的論文更好。說明什麼操作解決了問題，但你不需要重播整個故障排除過程。
除了禮貌和提供資訊之外，這種跟進還將幫助搜尋郵件列表/新聞組/論壇檔案的其他人準確地知道哪個解決方案幫助了你，從而也可能幫助他們。
最後，但並非最不重要的一點，這種跟進有助於所有協助者對問題感到滿意的了結感。問題敘述最終陷入未解決的虛無是很令人沮喪的；程式設計師渴望看到它們得到解決。撓癢癢所帶來的善意，下次你需要提出問題時會對你非常有幫助。
如果你無法獲得答案 如果你無法獲得答案，請不要因為我們覺得自己無法幫助你而感到難過。有時，被問及的群體的成員可能根本不知道答案。沒有回應與被忽略不同，雖然誠然從外面很難發現差異。
一般來說，簡單地重新發布你的問題是一個壞主意。這會被認為是毫無意義的煩人。要有耐心：有你的答案的人可能在不同的時區並且正在睡覺。或者可能是你的問題一開始就措辭不好。
溫柔一點。 與問題相關的壓力會使人們看起來粗魯或愚蠢，即使他們不是。
離線回覆初犯。 對於一個可能犯了誠實錯誤的人，沒有必要公開羞辱。一個真正的新手可能不知道如何搜尋檔案或 FAQ 儲存或釋出的位置。
如果你不確定，就說出來！ 一個錯誤的但聽起來權威的答案比沒有答案更糟糕。不要因為聽起來像個專家很有趣而把任何人引向錯誤的道路。謙虛而誠實；為提問者和你的同伴樹立一個好榜樣。
如果你不能幫忙，就不要妨礙。 不要拿可能破壞使用者設定的程式開玩笑 - 可憐的傻瓜可能會將這些解釋為說明。
提出探測性問題以引出更多細節。 如果你擅長這一點，提問者會學到一些東西 - 你也可能會。嘗試將錯誤的問題變成一個好問題；記住我們都曾經是新手。
雖然當回覆一個只是懶惰的傻瓜時，嘟囔 RTFM 有時是合理的，但指向文件（即使只是建議在谷歌上搜索一個關鍵詞）更好。
如果你要回答問題，那就給出好的價值。 當有人使用錯誤的工具或方法時，不要建議使用笨拙的解決方法。建議好的工具。重新構建問題。
簡介
在程式設計世界裡，你從技術問題中獲得的答案質量，很大程度上取決於你提問的方式，以及解決答案的難度。首先要理解的是，程式設計師實際上喜歡難題和關於它們的好問題，發人深省的問題。 如果我們不喜歡，我們就不會在這裡
程式設計師以對簡單問題表現出敵意或傲慢而聞名。有時看起來我們是對菜鳥和無知者的一種本能性的粗魯。 但這並非完全正確。
提問之前
在提出問題 a 之前，請執行以下操作- 嘗試透過搜尋你計劃釋出的論壇的檔案來找到答案。
- 嘗試透過搜尋網路來找到答案。
- 嘗試透過閱讀手冊來找到答案。
- 嘗試透過閱讀 FAQ 來找到答案。
- 嘗試透過檢查或實驗來找到答案。
- 嘗試透過向熟練的朋友提問來找到答案。
準備好你的問題。仔細思考。草率的問題只會得到草率的答案，或者根本沒有答案。
提問時
仔細選擇你的論壇 選擇提問的地點時要謹慎。如果出現以下情況，你很可能會被忽略- 將你的問題釋出到與主題無關的論壇
- 將一個非常基本的問題釋出到期望高階技術問題的論壇，反之亦然
使用有意義的、具體的標題 標題是你吸引合格專家注意力的黃金機會。不要把它浪費在諸如“請幫幫我”之類的閒聊上。不要試圖用你的痛苦程度來打動我們；而是用這個空間來寫一個超級簡潔的問題描述。
更一般地說，想象一下檢視問題存檔的索引，只顯示主題行。讓你的主題行充分反映你的問題，以便下一個搜尋與你類似問題的傢伙能夠跟隨該執行緒找到答案，而不是再次釋出問題。
用清晰的、符合語法的、拼寫正確的語言寫作
清晰地表達你的問題非常重要。花額外的精力來潤色你的語言。不一定要生硬或正式。但必須精確。
不要使用全部大寫字母；這會被解讀為喊叫，並且被認為是不禮貌的。
如果你像一個半文盲的笨蛋一樣寫作，你很可能會被忽略。所以不要使用即時通訊的快捷方式。
精確而翔實地描述你的問題
- 仔細、清晰地描述你問題的症狀。
- 描述問題發生的環境（機器、作業系統、應用程式等等）。
- 描述你在提出問題之前為理解該問題所做的研究。
- 描述你在提出問題之前為查明問題本身而採取的診斷步驟。
盡你所能預測回答者會提出的問題，並在你的求助請求中提前回答它們。
數量並不等於精確 你需要精確而翔實。簡單地將大量的程式碼或資料轉儲到幫助請求中並不能達到這個目的。如果你有一個龐大而複雜的測試用例，它正在破壞程式，請嘗試修剪它，並使其儘可能小。
這至少有三個原因很有用。一：投入精力簡化問題更容易獲得答案。二：簡化問題更容易獲得有用的答案。三：在改進錯誤報告的過程中，你可能會自己開發出修復或解決方法。
描述問題的症狀，而不是你的猜測 告訴程式設計師你認為是什麼導致了你的問題沒有用。所以，確保你告訴他們出錯的原始症狀，而不是你的解釋和理論。讓他們進行解釋和診斷。如果你覺得說明你的猜測很重要，請清楚地將其標記為猜測，並描述為什麼該答案對你不起作用。
描述目標，而不是步驟
如果你試圖找出如何做某事，請首先描述目標。然後才描述你被阻止的特定步驟。
通常，需要技術幫助的人腦海中有一個高層次的目標，並且卡在他們認為通往該目標的特定路徑上。他們來尋求該步驟的幫助，但沒有意識到該路徑是錯誤的。克服這一點可能需要大量的努力。
明確你的問題 開放式問題往往被認為是開放式的時間消耗。最有可能給你有用答案的人也是最忙的人（僅僅因為他們承擔了最多的工作）。這樣的人對開放式的時間消耗過敏，因此他們往往對開放式問題過敏。
如果你明確希望回答者做什麼（提供指標，傳送程式碼，...），你更有可能得到有用的回應。這將集中他們的精力，並隱含地為回答者必須分配的幫助你的時間和精力設定上限。
提問有關程式碼時
不要讓別人在不知道應該搜尋什麼樣的問題的情況下除錯你的錯誤程式碼。釋出幾百行程式碼，說“它不起作用”，會讓你被忽略。釋出十幾行程式碼，說“在第 7 行之後，我原本期望看到 <x>，但卻出現了 <y>”更有可能讓你得到回應。如果你只是想要程式碼審查，請提前說明，並務必提及你認為哪些領域可能特別需要審查以及原因。
不要釋出家庭作業問題
程式設計師很擅長髮現家庭作業問題；我們大多數人都自己做過。這些問題是給你自己解決的，這樣你才能從經驗中學習。可以要求提示，但不能要求完整的解決方案。用關於解決方案的簡短說明進行跟進
問題解決後，向所有幫助過你的人傳送一份說明；讓他們知道結果如何，並再次感謝他們的幫助你的跟進不必冗長而複雜；一個簡單的 “你好，這是一個失敗的網路電纜！謝謝大家。 - 比爾” 會好過什麼都沒有。
事實上，除非該解決方案具有真正的技術深度，否則簡短而簡潔的總結比冗長的論文更好。說明什麼操作解決了問題，但你不需要重播整個故障排除過程。
除了禮貌和提供資訊之外，這種跟進還將幫助搜尋郵件列表/新聞組/論壇檔案的其他人準確地知道哪個解決方案幫助了你，從而也可能幫助他們。
最後，但並非最不重要的一點，這種跟進有助於所有協助者對問題感到滿意的了結感。問題敘述最終陷入未解決的虛無是很令人沮喪的；程式設計師渴望看到它們得到解決。撓癢癢所帶來的善意，下次你需要提出問題時會對你非常有幫助。
如何理解答案
如果你不明白... 如果你不理解答案，請不要立即反彈要求澄清。使用你用來嘗試回答原始問題的相同工具（手冊、常見問題解答、網路、熟練的朋友）來理解答案。然後，如果你仍然需要請求澄清，請展示你所學到的東西。如果你無法獲得答案 如果你無法獲得答案，請不要因為我們覺得自己無法幫助你而感到難過。有時，被問及的群體的成員可能根本不知道答案。沒有回應與被忽略不同，雖然誠然從外面很難發現差異。
一般來說，簡單地重新發布你的問題是一個壞主意。這會被認為是毫無意義的煩人。要有耐心：有你的答案的人可能在不同的時區並且正在睡覺。或者可能是你的問題一開始就措辭不好。
如何以有用的方式回答問題
溫柔一點。 與問題相關的壓力會使人們看起來粗魯或愚蠢，即使他們不是。
離線回覆初犯。 對於一個可能犯了誠實錯誤的人，沒有必要公開羞辱。一個真正的新手可能不知道如何搜尋檔案或 FAQ 儲存或釋出的位置。
如果你不確定，就說出來！ 一個錯誤的但聽起來權威的答案比沒有答案更糟糕。不要因為聽起來像個專家很有趣而把任何人引向錯誤的道路。謙虛而誠實；為提問者和你的同伴樹立一個好榜樣。
如果你不能幫忙，就不要妨礙。 不要拿可能破壞使用者設定的程式開玩笑 - 可憐的傻瓜可能會將這些解釋為說明。
提出探測性問題以引出更多細節。 如果你擅長這一點，提問者會學到一些東西 - 你也可能會。嘗試將錯誤的問題變成一個好問題；記住我們都曾經是新手。
雖然當回覆一個只是懶惰的傻瓜時，嘟囔 RTFM 有時是合理的，但指向文件（即使只是建議在谷歌上搜索一個關鍵詞）更好。
如果你要回答問題，那就給出好的價值。 當有人使用錯誤的工具或方法時，不要建議使用笨拙的解決方法。建議好的工具。重新構建問題。