Stack Overflow 那些让人头大的规矩

stack overflow

今年 stackoverflow.com 已经上线十年，Stack Overflow 可以说是最好的软件类问答网站了，给软件开发人员工作和学习提供了非常大的便利，以至于像我这样的小白，离了 Stack Overflow 简直都不会写程序了。最近 Stack Overflow 的创始人之一，Joel Spolsky 更新了一系列 Stack Overflow 相关的文章，其中一篇讲为何给提问设置复杂的规则，读后受益匪浅，所以搬运过来，与大家一同分享。以下是原文链接：strange and maddening rules

提问前必要的准备工作

小黄鸭

程序员中流行着这样一种做法：当遇到难题时，掏出一只橡皮鸭子，向小鸭子逐行解释代码如何工作，应得到的结果是什么，实际上的输出是什么，等等。这方法看上去有点傻，不过试过的人都说有效。另外一种解决问题的技巧是分而治之。为了解决一个 bug，看成千上万行代码是不可行的，但是可以采用二分法，快速定位问题是在上半部分，还是在下半部分，这样重复五六次，就可以找到问题所在了。

了解了这些技巧，再看 Jon Skeet 的《问出好问题》，会发现很多有意思的东西。在文中，Skeet 向求助者抛出的一个问题是：有无仔细阅读自己的问题，问题描述是否通顺，是否包含足够的信息？这本质上就是橡皮鸭测试。文中的另外一个问题是：如果包含了代码，是否在保证可用 的前提下尝试精简代码？重点在精简上——这本质上就是看有没有尝试过分而治之。

Skeet 的文章在理想情况下，可以帮助人们在提问前，按照有经验程序员的思路，自己尝试分析问题。但不幸的是，很多人没读过 Skeet 的文章；也可能是看了，却不照着做；更可能的是，求助者正忙着解决紧急的 bug，听说 Stack Overflow 上可以解答，所以他们顾不上某个呆子写的冗长求助礼仪了。

Stack Overflow 欢迎新人

New York skyline

是否允许编程新手问初级的问题，是 Stack Overflow 上很常见的争论。Jeff 和我讨论 Stack Overflow 的最初设计时，我提到了 comp.lang.c，在 80 年代，comp.lang.c 是很火爆的 C 语言社区。C 是一门简单而且功能有限的编程语言，十万行内绝对搞的定一个 C 编译器。所以，C 语言的社区里，很快就会没有啥新东西可说了。

在 90 年代，C 是大学毕业生们都会学习的语言，而且事实上，毕业生们问的也都是非常基本的问题，这些问题大都抛在了 comp.lang.c 上。comp.lang.c 上的老鸟们实在是不胜其烦，厌烦于毕业生们每年九月份都要来问：为什么不能从函数中返回本地数组之类的让人无语的问题，真的是每年九月份都要接受一波洗礼啊。所以老鸟们发明了常见问题(FAQ)的概念，老鸟通过常见问题(FAQ)想表达的是：“再也别问之前问过的问题了。”更进一步的意思是，他们只想看到那些如此匪夷所思，如此难懂的问题，对于百分之九十九的 C 程序员都没有任何意义。comp.lang.c 慢慢失去了活力，因为它只迎合了在那里浸淫了很久的少数老手们 。

Jeff 和我讨论了一下这个事，我们应该怎么看待新手的问题？我们决定，对新手也该敞开大门，Stack Overflow 上没有太简单而不该问的问题......只要在问之前做足功课。我们也清楚这样做的风险，部分更资深的用户会因为厌烦重复的问题而离开，我们觉得这没问题，毕竟 Stack Overflow 也没提供啥终身相守的承诺是吧。如果因厌倦新人们总是问为啥不能返回本地数组（“但对我来讲，不是个事啊！”）而离开，他们还是会把余生贡献在更有价值的事情上，比如整理收藏的唱片专辑啥的。

刚刚起步不意味着不能在 Stack Overflow 上发问，为了证明这点，我特意在 Stack Overflow 上问了一个很初级的问题，来证明网站设是欢迎初学者的。因为非预期结果定律，这个问题还造成了不小的骚动，倒不是因为问题太简单了，真正的问题是我提问的态度不端正，Jeff Atwood 是这样说的：“简单没毛病，不下功夫研究可不行。”（亦见于此）

Stack Overflow 上提问为何如此麻烦

在 Stack Overflow 上问第一个问题时，新人们通常会感到这过程太复杂、太漫长了，有这个必要吗，这简直是在虐人啊。这个过程有点像火人节：报名时大家想的只是想参加沙漠里一场超酷的舞会，但过来人都抱怨那该死的火人节十律；而且这舞会也太疯了，跟邪教也相差不远了吧？这还不算完，刷碗的脏水一滴也不能倒，得像对待珍贵的圣水一样，随身带回家，七天的脏水，大家感受一下。每个社区都有许多规矩，有的古怪，有的讨喜，当然了，当你拼命修 bug 时，这些规矩就显得有点不太友好了。

许多火人节重要的规则都显得专横，但确实很必要。比如，美国土地管理局（他们负责审批火人节的沙漠用地）要求不能将污水倒在沙漠地面上，因为沙漠环境不能很好的吸收污水，这会造成各种疾病和未知的问题。但是谁在乎规则后面复杂的背景呢，所以很多正当的理由，在参与者眼里就变得很武断了。对于 Stack Overflow 也是一样，比如，我们不允许问太宽泛的问题（例如，我该怎么学编程？）我们的大原则是，如果问题需要一本书那么厚的答案，那这个问题就不太合适了。这种问题就感觉就像在一个医学网站上问：“我肾有点疼，怎么才能把它切除了？”这太荒唐了，将心比心，花了十年才当上外科大夫的人看到这种问题该怎么想。

Stack Overflow 未来的发展和挑战

当我们培育下一代的开发人员时，希望从下一代中看到更多的多样性和包容性，但有件事我非常担心，其实我们为下一代学习编程设下了不少的障碍。从很多方面来讲，Stack Overflow 设立的种种规则，都是障碍。但更大的问题是，新人提问时，老手们表现出来的粗鲁、尖刻和优越感。我个人是很看重这点的，成为一名开发人员给了人们无以伦比的编写未来的机会，而 Stack Overflow 上对新人们的严厉批评，对人们、社会和 Stack Overflow 自身都是有害的，因为这赶走了潜在的未来贡献者。编程已经够难了，我们的任务应该是让它变的简单一点。

未来几年，我们在这方面规划了很多事情，我们不能改变所有人，我们不可能强迫人们变的友好，但是我想我们可以改进某些 Stack Overflow 的用户界面，鼓励更友好的行为，例如我们可以改进“提问”页面的提示语，我们也可以为缓和社区里的过激评论做更多的努力，但目前是没有任何审查的。

结语

Trading protocol

我们也在开发一些新功能：可以把问题直接发送到用户建立的小组里，在这个更小、更私人化的环境里，可以让用户感受到比 Stack Overflow 大环境中更友好的体验。即使我们想把 Stack Overflow 做的更友好，我们的主要目标还是要把 Stack Overflow 打造成世界上最好的软件开发人员的资料库。世界上平均每个程序员会从 Stack Overflow 获得 340 次帮助，我们已经达成了目标，当然还有其他学习编程和求助的资源，但只有 Stack Overflow 在开发人员在心中如此重要，其中信息值得存留——就像编程世界里的美国国会图书馆（如果要以书籍的标准来要求问题和答案的话，自然要设立一定的规矩和门槛）。