专栏首页前端之旅如何在 Stack Overflow 规范提问

如何在 Stack Overflow 规范提问

前言:

最近学习js的时候看到了一段代码,思考再三之后仍然不是很理解,于是决定到尽可能多的平台进行提问,目的有二:1.最主要的,解决问题;2.借这个机会测试哪些平台可以在短时间内给予提问者反馈和援助,从而作为下次提问的首选之地。最后问题是解决了,但是关于提问这件事再次有了不一样的感想。

首先从我自身出发—-在中文环境下我能够做到比较规范的提问(我认为的规范),即

  • 表诉清晰
  • 必要的答谢

但是在英文环境下就显得吃力得多,暴露的缺点如下:

  • 表达不够地道清晰,误导了回答者,导致问题被认为是duplicate而被关闭
  • 编辑问题后未进行必要的核查,导致了后期的修改
  • 无法完全理解对方想要表达的意思

其次从平台出发进行分析,不得不说国内的平台反馈速度和热情的确比不上国外的。知乎因为有邀请机制,所以问题还是有机会得到高手的点拨;SegmentFault本身定位就是中国的Stack Overflow,所以得到专业回答的可能性也比较大。 但是类似贴吧和QQ群这些交流平台,得到有效回答的机率却实在太低。本来QQ群是实时互动的,反馈更应该迅速点,但是很多时候问题会被忽略。是什么原因我就不说了,不好直接下定论,但这无疑提示了我:如果急着解决问题,就应该避免在这些地方浪费时间—-一来速度没保障,二来质量参差不齐。

理想的提问平台应该是SegmentFault或者Stack Overflow。关于如何在Stack Overflow规范提问,这里转载一篇不错的博客:

规范提问指南

可以问什么样的主题

大家都知道 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 即可。

交流

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

术语词汇

2019.5.3 更:

近期找到了一个更好的平台(掘金翻译计划),它拥有完善的流程把控和工作分配,这其实正是我很久以前试图在汉化工作中寻找但是没有找到的东西。其实这是一件值得长期投资的事情:

1.最主要的目的,锻炼阅读英文技术文档的能力,同时积累术语词汇; 2.熟悉 github 的操作 3.据说 200 积分可以换一台kindle(虽然听起来遥遥无期,但是可以作为动力哈哈哈)

当然,这个工作不会很轻松,不过完事开头难是很正常的,希望我可以坚持下去吧。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 操作系统学习笔记-3:初识进程和进程控制

    在 操作系统学习笔记-1:基础概念) 中,我们介绍了与操作系统相关的一些概念,在 操作系统学习笔记-2:体系结构设计和运行机制) 中,我们又介绍了操作系统的结构...

    Chor
  • 谈一谈JavaScript的内存模型

    对我们程序员来说,声明变量、进行初始化和赋值几乎是每天都在做的一件事情。不过,这些操作本质上做了什么事情呢?JavaScript 是如何在内部对这些进行处理的?...

    Chor
  • 「译」创建一个Hexo主题-Part2:其他页面

    在这个系列教程中,你将学习怎么从零开始制作一个 Hexo 主题。 在 part1 中,我们已经着手动工并创建了首页。在这篇文章中,我们将运用所学完成剩余的页面。

    Chor
  • 关于C++编译链接和模板函数

    一,关于编译链接 编译指的的把编译单元生成目标文件的过程 链接是把目标文件链接到一起的过程 编译单元:可以认为是一个.c或者.cpp文件。每个编译单元经过预...

    xcywt
  • 赶快来更新你的bootloader吧

    不知大家是否还记得在之前给大家介绍过NXP的kinetis bootloader1.2版本的, 嵌入式工程师必须会的技能:玩转bootloader 时隔一年多,...

    用户1605515
  • 深入理解浏览器原理

    ? 导语:本文从市面主流的浏览器及相应的内核引擎开始,介绍了Chromium为代表的浏览器架构及Blink内核的功能架构。Chromium为多进程架构,用户从...

    腾讯技术工程官方号
  • 每天都在用的浏览器,你知道它是如何工作的吗?

    浏览器经历了很多年的发展,浏览器引擎也在不停地迭代和演进。从PC时代到移动端,以独立浏览器的形态还是以系统WebView组件内嵌的形态存在,在互联网的生态系统中...

    iMike
  • 关于政务移动门户的新思考

    上表为学者研究的政务渠道与若干指标项的比较[1]。同时,从电子政务的信息补偿理论[2]出发,拥有一个可控、自有、权威的信息发布平台对于政府公信力的提升是可行的。...

    面具无双
  • C#2.0新增功能03 匿名方法

      在 2.0 之前的 C# 版本中,声明委托的唯一方式是使用命名方法。 C# 2.0 引入匿名方法,在 C# 3.0 及更高版本中,Lambda 表达式取代匿...

    张传宁老师
  • 最近的海外面试(前端)经历

    http://pinkyjie.com/2017/02/21/recent-overseas-interview-experiences/

    bear_fish

扫码关注云+社区

领取腾讯云代金券