Stack Overflow 那些让人头大的规矩

字数 2475阅读 6118
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 上提问为何如此麻烦

image

在 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 在开发人员在心中如此重要,其中信息值得存留——就像编程世界里的美国国会图书馆(如果要以书籍的标准来要求问题和答案的话,自然要设立一定的规矩和门槛)。

推荐阅读更多精彩内容