Stack Overflow 上古怪恼人的规矩

Stack Overflow| 2018-05-24

图0：Stack Overflow 上古怪恼人的规矩

stack overflow

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

strange and maddening rules

图1：Stack Overflow 上古怪恼人的规矩

小黄鸭

程序员中流行着这样一种做法：当遇到难题时，掏出一只橡皮鸭子，向小鸭子逐行解释代码如何工作，应该得到的结果是什么，实际上的输出是什么，等等。这么做的程序员都说这种看起来有点傻乎乎的方法，确实有效。

另外一种解决问题的技巧是分而治之。为了解决一个 bug，看成千上万行代码是不可行的，但是可以采用二分法，快速定位问题是在上半部分还是下半部分，这样重复五六次，就可以找到问题所在了。

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

Skeet 的文章在理想情况下，可以帮助人们在提问前，按照有经验程序员的思路，自己尝试分析问题。

但不幸的是，不是所有人都读过 Skeet 的文章，也可能是看了，却不照着做。更可能的是他们遇到了紧迫的代码问题，听说 Stack Overflow 上可以解答，所以他们没有时间读某个呆子写的冗长求助礼仪。

图2：Stack Overflow 上古怪恼人的规矩

是否允许编程新手问初级的问题，是 Stack Overflow 上很常见的争论。

在 Jeff 和我讨论 Stack Overflow 的最初设计时，我提到了 80 年代非常流行的一个关于 C 语言的 Usernet 讨论组，名字是 comp.lang.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 上发问，为了证明这点，我特意问了一个很初级的问题，希望能留下一些网站设计者欢迎初学者的证据。

因为非预期结果定律，这个问题还造成了不小的骚动，倒不是因为问题太简单了，真正的问题是我提问的态度不端正，Jeff Atwood 是这样说的：“简单没问题，不下功夫研究就不行了。。”（亦见于此）

对新人来说，经历在 Stack Overflow 上问第一个问题的冗长复杂过程时，要么觉得这完全没必要，要么觉得太怪异了。这有点像火人节：只是想去沙漠里参加一场超酷的舞会而已，但是参加过的人都在抱怨那该死的火人节十律、极端的自我表达等等，这还不算完，刷碗的脏水一滴不能倒，必须像对待珍贵的圣水一样，随身带回家。每个社区都有许多规矩，有的古怪，有的讨喜，当然了，当你拼命的想让代码正常运行时，这些规矩就显得古怪而恼人了。

许多对火人节成功非常重要的规则都显得专横，但他们确实很必要，负责审批火人节沙漠用地的美国土地管理局，要求不能将污水倒在地面上，因为泥土不能很好的吸收，这会造成各种疾病和未知的问题。但是谁在乎规则后面复杂的背景呢，所以很多正当的理由，在参与者眼里就变得很武断了。

对于 Stack Overflow 也是一样，比如，我们不允许问太宽泛的问题（例如，我该怎么学编程？）我们的大原则是，如果问题需要一本书那么厚的答案，那这个问题就不太合适了。这种问题就感觉就像在一个医学网站上问：“我肾有点疼，怎么才能把它切除了？”这太荒唐了，而且这问题对哪些花了十多年来学习如何成为外科医生的人也不够尊重。

当我们教育下一代的开发人员时，希望从下一代中看到更多的多样性和包容性时，有件事我非常担心，就是在我们为下一代学习编程时所设下的障碍。从很多方面来讲，Stack Overflow 设立的什么是允许的，什么是禁止的规则，都是障碍。但更大的问题是，新人提问时，老手们表现出来的粗鲁、尖刻和优越感。

我个人是很看重这点的，成为一名开发人员给了人们无以伦比的编写未来的机会，而 Stack Overflow 上对新人们的严厉批评，对人们、社会和 Stack Overflow 自身都是有害的，因为这赶走了潜在的未来贡献者。编程已经够难了，我们的任务应该是让这变的简单一点。

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

图3：Stack Overflow 上古怪恼人的规矩

Trading protocol

我们也在开发一些新功能：可以把问题直接发送到用户建立的小组里，在这个更小、更私人化的环境里，可以让用户感受到比 Stack Overflow 大环境中更友好的体验。

即使我们想把 Stack Overflow 做的更友好，我们的主要目标还是要把 Stack Overflow 打造成世界上最好的软件开发人员的资料库。世界上平均每个程序员会从 Stack Overflow 获得 340 次帮助，我们已经达成了目标，当然还有其他学习编程和求助的资源，但只有 Stack Overflow 在开发人员在心中如此重要，其中信息值得存留——就像编程世界里的美国国会图书馆（如果要以书籍的标准来要求问题和答案的话，自然要设立一定的规矩和门槛）。

本文文字及图片出自 www.jianshu.com