橡皮鴨子解決問題法

在 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. 如果您喜歡這篇文章並且希望學習程式設計技術的話，請關注一下 復唧唧。