在 Stack Exchange 上，我們一直強調，提交問題的人應該在提問前多花點時間研究一下他們的問題，而且我們對此非常偏執。就是說，當你提交問題時，你應該…
- 描述問題要足夠詳細，以便我們能跟上你的思路。提供必要的背景信息，幫助我們理解發生了什么事情，即使我們不是你所在領域的專家。
- 告訴我們為什么你需要知道這個問題的答案。是什么讓你找到這兒來尋找答案的？你提的問題是出于好奇心，還是在某個項目上遇到了阻礙？我們不需要知道你全部的故事細節，這樣做，只是需要在這兒給我們一些上下文的提示。
- 分享你在該問題上面所做的研究。迄今為止你發現了什么？為什么它不能有效工作？如果你沒有做任何研究 ... 你應該提交這個問題嗎？如果你邀請我們花費寶貴的時間幫助你，你應該花同樣合理的寶貴時間設計一個像樣的問題，唯有這樣才是公平的。幫助我們也是幫助你自己！
我們有一個非常好的如何提問頁面（How to Ask page）解釋了這些事宜。（并且在 Stack Overflow 上，由于問題太多，我們的確要求新用戶在提交他們的第一個問題之前去訪問那個頁面。作為一個新用戶在提交第一個問題前，你自己就能看到這個頁面。）
我們極力避免的，也是最最重要的，是那些無法回答的問題。這些問題對任何人都沒有幫助，但是若任其發展卻可以毀掉一個問答網站，將其變成一個虛擬的鬼城。在 Stack Exchange 上，那些缺乏背景信息和上下文以至于不能被合理回答的問題，將被立即關閉，然后如果情況不能得到改進的話，最終將被刪除。
正如我之前所說的，我們對此非常偏執。我們認為，通過教授橡皮鴨子問題解決法（Rubber Duck problem solving），是一個明確地幫助你自助解決問題的好理由。而且，這樣做一直以來都非常有效。在數年的時間里，我已經從 Stack Overflow 或者 Stack Exchange 其它子站上得到了大量的反饋，就是說，在以這樣的方式撰寫具體問題的過程中，最終他們想出了自己問題的答案。
這種事已經非常司空見慣了。不信的話你自己看：
迄今為止我只發布過一個問題，而且差點提交了另一個。這兩次經歷，最終都是在我撰寫問題的過程中，我至少部分地解答了自己要問的問題。我之所以能夠想出答案，這要歸功于社區以及描述問題的過程。當我描述問題時，并沒有與答案有關的明確線索，但當問題寫完之后，卻讓我產生了考慮該問題的另一條思路。
我不知道這已經發生多少次了：
- 我有一個問題
- 我決定把它放到 stackoverflow 上面
- 我粗略地將問題寫下來
- 我知道該問題描述的不好
- 我又花費了15分鐘時間重新思考該如何描述問題
- 我意識到自己正在一個完全錯誤的方向上解決問題
- 我再次從頭開始，并且迅速找到了問題的解決方案
上述這樣的事情是否也發生在你身上呢？有時候，提出正確的問題，似乎問題就已經解決一半了。
開始提出一個問題，實際上是在幫助我調試我自己的問題，尤其為了得到像模像樣的的答案時，我們總是會提供足夠詳細的與問題相關內容。這樣的事情以前是否在別的人身上發生過？
這不是一個什么新東西，只要給予足夠的時間，每一個互聯網社區似乎都能找到自己的解決問題方式，但是“向鴨子提問”的確是一個非常強大的解決問題的技巧和方法。
鮑勃指著辦公室的角落，“在那兒”，他說，“有一只鴨子。我希望你向那只鴨子提出你的問題。”
我看著那只鴨子。事實上，它吃的很飽，一動不動。即便它還能動，也不可能是一個有關設計信息的有效來源。我看著鮑勃。鮑勃看起來很認真。當然，他是我的上司，我不想失去這份工作。
我搖搖晃晃地向鴨子走了過去，并且站在了它的旁邊。我開始低下頭和鴨子交流，看起來有點像在祈禱。“你，” 鮑勃問，“在干什么？”
鮑勃的一位上司正巧在他的辦公室。他開心地大笑起來。
“安迪，”他說，“我不是讓你向鴨子祈禱，我是讓你向鴨子問問題。” 我舔了舔我的嘴唇。“大聲嗎?” 我說。
“大聲，” 鮑勃堅定地說。
我清了清嗓子。“鴨子，” 我要開始了。
“它的名字叫小鮑勃，” 鮑勃的那位上司補充了一句。我冷冷地瞥了他一眼。
“鴨子，” 我繼續說，“我想知道，當你使用 U 形夾掛鉤，在管道頭部排水時，怎樣防止噴水管彈出 U 形夾，導致管…”
在我向鴨子問問題的過程中，我得到了問題的答案。U 形夾掛鉤是懸掛在螺紋桿上面的。如果管道安裝工將螺紋桿鋸到一定長度，使其緊緊頂在噴水管頂部的話，實際上管子已經被固定在掛鉤上了，這樣也就防止了管子的突然脫落。
我轉頭看向鮑勃。鮑勃在點頭。“你知道答案了，是這樣嗎？” 他說。
“應該把螺紋桿緊緊頂在管子的頂部，” 我說。
“完全正確，” 鮑勃說。“下次你再有問題，我還讓你來這兒繼續問鴨子，而不是問我。大聲地問它。如果你仍舊無法得到答案，你再來問我。”
“好的，” 我說，然后就回去繼續工作了。
我很喜歡這個特殊的故事，因為它講解地十分清楚 - 解決橡皮鴨問題的關鍵部分是向這個虛構的人物或靜物問一個深入且足夠詳盡的問題。是的，即使你最終沒能解決這個問題，起碼你可以意識到自己犯了一些愚蠢的錯誤。向虛構的人物問問題，要一步一步來，并且要盡量詳細，這種嘗試經常能讓你找到問題的答案。如果你不愿意花費精力去完整地說明問題以及試圖解決該問題的過程，那么在你詢問其他人之前，你就不能得到深度思考你的問題所帶來的好處。
如果你在編程上缺少伙伴（但是你絕對應該有），你可以利用橡皮鴨問題解決法這樣的技巧找出答案，當然這全部要靠你自己，或者利用偉大的互聯網在社區中尋求答案。即使你沒有得到你想要的答案，強制自己完整地描述自己的問題 - 最好以書面形式 - 往往就會產生新的認識和發現。
作者：Jeff Atwood，程序員，著名博主，Stack Overflow / Stack Exchange & Discourse 聯合創始人及發起者。
原文： Rubber Duck Problem Solving
感謝： Jodoo 幫助審閱并完成校對。
P.S. 如果您喜歡這篇文章并且希望學習編程技術的話，請關注一下 復唧唧。
