橡皮鸭子解决问题法

在 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. 如果您喜欢这篇文章并且希望学习编程技术的话，请关注一下 复唧唧。