封面

StackOverFlow提问的艺术

stackOverFlow现在不仅是一个社区,更是一个程序员的聚集地,就像古代高手云集的江湖。合理的使用它不仅能够方便自己,更能够帮助别人。我最喜欢的两个网站:githubstackOverFlow

提问相关

可以问什么样的主题

大家都知道 Stack Overflow是编程类的问答社区, 但还真有人把它当成通用的问答社区了, 问些完全无关的问题。 其实, Stack Overflow 是有一系列兄弟网站的(目前已经有100+), 统称 Stack Exchange, 涵盖很多主题, 比如数学、物理、化学等科学类, 服务器管理、Latex、数据库等计算机类, 中文、俄文、日文等语言类, 详细的列表看这里, 不要让好问题问错地方哦。
允许的主题包括: 具体的编程问题、软件算法相关、通常只有程序员用的软件工具相关等。
有些主题是比较容易弄错的, 比如一般的电脑操作问题, 应该去Super User(热门的 Linux/Unix, 和Ubuntu还有独立的站点), 专业的服务器问题, 应该去Server Fault。这些都不属于编程类的问题, 尽管不少程序员的日常工作也有涉及(想一想“怎么修电脑?”属于编程问题么)。 再举个例子, 同样是编辑器, Vim/Emacs/Atom相关的问题是可以的,因为基本只有程序员会用这些工具, 而 Word/记事本相关的一般就不可以。

什么样的问题应该避免问

编程相关还不够, Stack Overflow 要求问题必须是 「practical, answerable questions based on actual problems that you face」。
这是什么意思呢? 首先, 开放式的问题是不允许的,比如“你为什么喜欢PHP?”, 隔壁Quora会是更合适的对象。 其次, 问题应该不需要很长的篇幅来回答, 如果一个问题期待的回答足够写一本书, 那很可能会被关闭的。 各种寻求资源的问题应该避免,如 “要完成某某工作, 有什么Python的库可以用”, 或者“学习C++应该选择哪本书?”等, 因为答案会主观, 也容易吸引广告。 最后, 问题不要基于凭空的假设,要基于实际的难题。
需要注意的是,你很可能见过一些违反上面规定的问题还在,而且浏览量很大, 尤其是一些寻求资源的问题, 和非编程相关的计算机问题等。 这是什么原因呢? 原来,早期的Stack Overflow的规则还比较松,也没有Super User之类的站点。 这些问题往往是08/09年问的,大多数现在已经被关闭了。
上面的规则如果遵守, 你的问题应该问对地方了。 下面继续说说内容上具体需要注意的。

直入主题

Stack Overflow不是论坛, 它的目标是希望成为编程类问答的一个超级数据库, 所以每个问题都不止是为了帮助提问者本人, 更重要的是希望将来能够帮助到每一个遇到同样问题的人。
所以, 和问题无关的内容都被认为是一种噪音, 包括: 打招呼(比如 Hi, Hello, Good afternoon, Dear Coders等), 表示感谢(比如 Thanks, Any help would be appreciated等), 没必要的背景(比如 I’m a newbie in C#等), 你的签名 等。
可能有人会不理解为什么这样规定, 尤其是不要表示感谢这点。 Stack Overflow社区的理由是, 对愿意阅读并尝试解答你问题的人来说, 最好的表达感谢的方式是upvote有帮助的回答, 以及选择其中一个作为答案。 每一句和问题无关的内容都增加了额外的阅读时间, 而一个问题可能会被大量的人阅读。 更多的相关讨论可以参见这里和这里。
同样道理, 当有人回答你的问题之后, 也不要去添加无用的评论, 比如单纯的表达感谢的话, “+1”, 或者闲聊等。 评论的唯一用处是用来澄清疑问。

英语

作为一个英语社区, 不论提问、回答还是在评论中和别人互动, 都是要用英语的。
除非英语水平真的很糟糕, 语法其实并不是最需要担心的,因为并不需要做到完美。Stack Overflow是允许自由的编辑其他人的问题/回答的(编辑者如果rep不到2K,需要经过评审才会生效)。 有很多人会热情的对问题进行编辑的, 包括修复可能的语法错误。 我想说的一点是, 要尽可能的保证单词拼写是正确的。 即使对英语不够好的人来说, 这也只需要多花一点时间检查就可以做到, 但它代表着对阅读你问题的人的尊重。 甚至很多英语母语的人在拼写上也不注意, 会把I’m 写成im, 把 want to写成 wanna之类的非正式英语, 这些都会降低问题被回答的概率。

内容

在发问题之前, 问自己几个问题:

  • 你做过足够的研究么? 有的人连入门指南都没读上10分钟就去提问, 问的问题能有多少价值呢?
  • 你尝试过搜索么? 至少要试过Google和站内搜索, 很可能相同的问题已经有答案了
  • 你试过debug么? 把你的想法或调试过程写在问题里,否则很可能会看到几条评论“Have you tried anything?”或“We don’t do your homework”之后问题就被downvote得惨不忍睹了。 因为大多数人是拒绝回答没有努力尝试的提问者的。
  • 标签: 一个问题可以加1~5个标签, 大多数问题是和某种具体的编程语言相关的, 这个语言的标签通常是必须的, 否则相关语言的关注者们很可能根本见不到问题。

起一个好标题

一般来说, 标题应该尽量用简介的语言描述具体的问题。 比如 C# number confusion就是个反例, 如果改成 Why does using float instead of int give me different results when all of my inputs are integers? 就要具体多了。

提供代码

对于编程类问题,的确有问题不需要代码也能表达清楚的, 但大多数问题都需要代码才能清晰的表达。“我声明了一个变量, 调用了几个函数, 然后它的值就变了, 为什么呢?” 这样的问题, 鬼才知道答案。
提供代码要注意: 不要贴截图, 难道你要回答者去照着截图敲键盘复现你的问题? 也不要只贴站外的链接, 如果站外链接能够提供一些额外的方便功能, 也要在贴代码的基础上附上该链接。
对于提供什么样的代码, Stack Overflow给出了一个可参考的标准: MCVE, 即Minimal, Complete, and Verifiable example
Minimal: 最小的, 也就是尽可能的去掉和问题无关的部分。 如果你贴了一个几百行的代码, 很少有人愿意花时间去仔细看。 构造最小化例子的过程本身也是debug的过程。
Complete: 完整的, 一个简单的判断是:别人看到问题, 可以通过复制你提供的代码复现出问题吗?
Verifiable: 可验证, 描述问题尽可能具体, “the code doesn’t work”这样的描述就很不好。 如果编译不过, 要加上编译错误信息; 如果运行报错, 也同样要加上具体的错误信息; 如果结果和你的预期不一致, 要说清楚你的预期结果是什么, 为什么会这样想。
格式
Stack Overflow的编辑器是Markdown格式的, 如果你还不熟悉, 建议去学一下, 因为Markdown真的是一个只要10分钟就可以学会的语言。
大多数的格式问题都是出在贴代码的地方, 如果你发现你的代码是普通文本, 而没有语法高亮等功能, 那你很可能是格式搞错了。 最方便的方法就是选择所有代码, 然后按键盘Ctrl + K 即可。

交流

有可能你的问题几分钟内就会有人回答, 也有可能有人对问题有疑问, 在评论中要求你解释。 可以评论@他们解释, 如果问题确实不够清晰, 编辑你的问题吧。 最后, 如果你自己发现了解答方法, 而还没人给出, 那就自己回答自己的问题吧。 自问自答是被鼓励的行为。

结语

看完上面我的唠叨, 是不是也感觉到Stack Overflow对新手的不友好了呢? 但这是保持高质量内容的代价之一, 必须有一定的机制让低质量的问题不会泛滥, 才会有更多的人愿意花时间回答好的问题。 希望大家都能得到自己问题的答案, 有机会再讲讲如何回答问题。

提问前的自问

提问之前你做过研究吗? <注1>
你是否说明了自己试过哪些方法解决问题?
你说明你使用的编程语言/平台了吗, 包括版本号?
如果你的问题包含代码, 你是否已经改写成最小且完整的程序?<注2>
如果你的问题包含代码, 你是否检查过代码格式?<注3>
如果你的代码不能编译, 问题中是否包含了编译错误信息?
如果你的问题不包含代码, 你确认不需要吗?
如果你的程序抛出了异常, 问题中是否包含异常信息和堆栈回溯(stack trace)?
如果你的程序的输出结果和预期不同, 你是否说明了你的预期结果是什么, 你为什么这么想, 以及程序的实际结果?
如果你的问题和本地化有关(语言,时区等), 问题中是否包含了相关的信息?
你是否检查过问题的格式是否正确?
你是否检查过拼写和语法?<注4>
你是否认真读过自己的问题, 确认问题对一个不了解问题背景的人也能明白?
如果以上任何一个问题的答案是否定的话, 很可能你提问前需要再修改一下问题。 我知道这听上去像是不少工作, 但它能帮助你尽快的得到答案。别忘了你是在请求他人用自己的善心帮助你, 你有义务让他们的工作尽可能的简单。

注1: 如果你从“这怎么不工作了”到“应该去问个问题”只花了不到10分钟, 那很可能你的研究还不够。
注2: 理想情况下, 你的代码应该可以让回答者复制, 粘贴到编辑器, 编译, 运行, 然后就能看到问题输出。 命令行程序适用于这样的标准(除非你的问题和用户界面有关, 最好用命令行程序)。 去掉任何和问题无关的代码, 但保证可以复现问题。
注3: 代码最好不需要水平滚动, 这可能需要你从IDE复制代码之后做些额外的处理。 为了那些愿意帮助你的人花点时间把问题表达清楚吧。
注4: 我明白很多Stack Overflow用户母语不是英语, 我们并不要求完美, 只是希望你做过努力。如果你清楚自己英语不好, 找一个同事/朋友帮你改改吧。k

答题相关

想法的萌芽

如果非要总结下我多年来是如何使用Stack Overflow的话,我的答案就是:打开网页,搜索问题,查看Stack Overflow的搜索结果,参考答案,最后再关掉网页。

我的生活已经离不开Stack Overflow了。但我从来没有对那些有用的回答做出过反馈,更别提自己提问题和回答问题了。

不过我最终还是意识到,Stack Overflow的成功正是建立在其众多用户的慷慨解答上。我从这个网站上收获了很多,却从未做出回报,因为没有任何人、任何规则的约束。每个问题、每个答案或者每个有帮助的评论的出现只是因为某人慷慨的写了出来。诚然,Stack Overflow也有一套激励机制去帮助它的发展,且用户获得徽章和威望的多少也是个未知数,且通常由其他用户决定。例如,如果你提了一个问题或者回答了一个问题,没有人有义务去赞同或者反对你。

多年来,我一直受益于它,但未对它尽过绵薄之力。我在网站上找到过一打有帮助的答案,但我甚至不曾为它们点个赞。

是时候回报Stack Overflow了!

目标

某天我在浏览徽章列表时发现,可以通过连续30天访问网站而获得一枚银色勋章。于是我决定将这个作为我的目标,通过30天不间断地浏览网站并且达到1000威望值。但我将只回答问题而不提问。

完成情况

正如下表所示,我只能算是勉强完成目标。

尽管我发现在访问量达到200的时候就会有100点威望值的福利作为回报,但是我也依然有一整个星期都颗粒无收的瓶颈期。理解并回答问题无疑是一个缓慢并需要一定方法的过程,要想达到我的目标,至少需要每天30点左右的威望值进账才可以。

##经验之谈

Stack Overflow看起来就像一个纯粹的问答网站,但在我花了30天沉浸在回答问题的过程中后,发现了网站本身以及它所形成的社区的一些微妙的特点。以下是我所学到的一些:

“摘樱桃”

没过多久我就发现了网站上用户提问的速度之快。而我每天要做的只是:每小时花上几分钟刷新下问题页面,随机淘汰几个简单、不圆满的答案而已。除此之外,网站上的一些友好(有时并不十分友好)的竞争状况也显而易见。

我从择优的过程中学到了很多。

首先,确保你理解了问题。读完整个问题并且明确提问者想要的答案。如果你没有理解的话那么在评论中礼貌的问清楚。阅读标签也同样重要。不止一次我错误的回答了一个问题只因我自己假定了提问者所用的环境,显然这种情况可以通过阅读标签避免。

其次,不要为了快点回答问题而牺牲了答案的质量。错别字和语法错误不会对任何人有帮助,并且这些都可以通过放慢回答速度以及在提交答案前检查一遍来避免。换一种方式来说:拥有良好的书写格式和完整的答案更容易得赞,而残缺的答案自然不会。不要只为了回答问题而写一个快速但不完整的答案,然后不得不忙着补充忘记的点。我见过太多这样的答案,这样做也只会招来其他用户甚至包括操作员要求更多的解释。这种行为明显不利于用户提问和回答的发展。

最后,如果你正在撰写一个答案,一定要看一下已经存在的答案。如果你的答案和别人的几乎一样,那么你只需为别人的答案点个赞。如果他们的答案中缺了某些方面,那么你只需要在该答案的评论中去补充一下就可以了。

求助吸血鬼

Stack Overflow上有一群被称为”求助吸血鬼”的人。这些用户以“从不放过任何机会获得别人的帮助 “而闻名。这种现象一直存在,可我一直不知道他们甚至有个专属用词,直到某天有个用户斥责一位问题提问者为“求助吸血鬼”我才知道。

我就曾经为几个看起来像“求助吸血鬼”的用户回答过问题,接着就一发不可收拾了。他们通常采纳了我的答案接着在再答案下留言问一些新的毫无关系的新问题。

我的处理方式就是(建议其它用户在遇到这种情况时也这样):写一个评论告诉用户他的所作所为是不对的以及应该怎么做。当时我就建议他去Google一下这个新问题,如果找不到想要的答案再来Stack Overflow上问一个新的问题,而不是在一个用户的答案下不停的问一些毫无关联的问题。

上面给出的Meta Stack Exchange链接上提供了很多在遇到这种求助吸血鬼时的有用回应。我还想说的一点就是,当普遍认可的答案却得到质疑时,首先应该做的是在该问题下做出评论,解释提问者可以自己修正这个问题。给用户一个改正自己错误的机会。这样的话,用户可能更能从这个网站上学到新的东西,你甚至还能为网站审核者节省时间!

卖弄狼人

卖弄狼人,我专门为与“求助吸血鬼”所造的名词。对于求助吸血鬼们来说,这些原本可能善意的用户简直就是恶魔的化身。

当我发现求助吸血鬼的现象越来越严重的时候,有些用户采用粗暴且无用的方法制止他们。卖弄狼人们通常这样说:“这明显是一个家庭作业水平的问题”,“你难道都不试着Google一下么”,“不要问重复的问题!”。当我完成我的30天目标时,比起求助吸血鬼,我更烦这些卖弄狼人。

我想对这些人说:请回答的更具建设性和有用一点。为提问者提供更常规的答案。我的这些建议对提问者也同样适用!如果你遇到一个卖弄狼人只需要忽视他们就行,树立一个好榜样,不要在评论里面针锋相对!

关于反对票

在这30天里,我一直尽我最大的努力为提问者做出一个好的、详细的答案。但是有时候会出现这样的现象:某个我的被采纳了的答案竟然没有一个人赞同,反而都是反对。

这些否定深深得伤害了我。那些不赞同我的答案的用户都没有解释原因,甚至在我追问后也没有给出回答。我的答案被接受了,显然对于提问者来说这是一个好答案,但是我至今不懂为什么有那些反对票,甚至让我丢了两点威望值。

Stack Overflow上并没有强制要求你在反对某个答案的时候解释原因,这样郁闷很久后,我觉得网站应该这样有这样的机制。在一个反对票下做出解释是体现网站人性化的一面。

如何人性的在反对票下留言呢?我想了两种方法:

  • 如果有人已经在反对票中的评论解释了为什么投反对票,那么你只需要赞同一下这个评论就能引起回答者的注意了。
  • 如果没有人解释你投反对票的原因,那么就在评论中写出问题或者答案需要改进的地方。

声明:

我只是个萌萌的搬运工,待我也在stackOverFlow上修行完成之后再来谈自己的经验。

相关文章

文章目录
  1. 1. 提问相关
    1. 1.1. 可以问什么样的主题
    2. 1.2. 什么样的问题应该避免问
    3. 1.3. 直入主题
    4. 1.4. 英语
    5. 1.5. 内容
    6. 1.6. 起一个好标题
    7. 1.7. 提供代码
    8. 1.8. 交流
    9. 1.9. 结语
    10. 1.10. 提问前的自问
  2. 2. 答题相关
    1. 2.1. 想法的萌芽
    2. 2.2. 目标
    3. 2.3. 完成情况
    4. 2.4. 求助吸血鬼
    5. 2.5. 卖弄狼人
    6. 2.6. 关于反对票
  3. 3. 声明:
    1. 3.1. 相关文章


twitter分享


如果想及时收到回复,可在 订阅中心Participating中勾选Email

Fork me on GitHub