有时候提一个问题的姿势,比提什么问题更加重要。

注: 本文最早是发在一个学习论坛上的 帖子。后有所删改。

tl;dr

本文的论点1:在你用尽浑身解数之前,请不要轻易发问题。
本文的论点2:请用心问一个问题。

如果对其中的论点有异议的,欢迎留言反驳。也欢迎点击左(Win用户右)上角的叉叉。

在我遇到一个坑时

其实我经常遇到坑,而且经常自己坑自己。之所以没有让其他人耻笑的原因只是我没有告诉别人(逃

自己给自己挖坑的情况包括但不限于:

  1. Typo
  2. 没保存
  3. 没刷新
  4. 没重启
  5. 没脑子(对的,搞了半天,想错了

其实我觉得前4点已经占了 95% 以上的情况。可能我不是一个老司机,所以智商比较捉急(逃

因为跳了太多(自己的)坑,所以当我遇到一个”坑”时,我的反应是(按先后顺序排列):

  1. 这是我自己挖的么?
  2. 我有没有重启/刷新/保存?
  3. Debug

下文将讨论解决问题的流程。

1. Debug

这个问题太大,随便选门语言框架的 debug 话题就可以扯很久。我对 debug 的理解是:

  1. 搜集并分析 log
  2. 工具
  3. 其他方法

前两点我相信大家会懂。如果不懂的话可以看下一章(嗯,其实下一章没有提工具,哈哈哈哈哈)。其他方法包括但不限于:

  • 二分排除法
  • 断点
  • Print

2. 搜索

xxx 是什么?

这是我在论坛/群组里见过的最多的问题。康忙,现在是一个互联网时代。

你不需要别人告诉你这是什么,网络上你能找到关于一个名词的一切。

但是这里会有三个问题:搜索渠道、搜索内容和搜索技巧。

搜索渠道

首先,请谷歌。(抛开某度难看的吃相,在百度上搜技术问题简直就是慢性自杀
如果无法谷歌,请尽最大努力来进行翻墙。
如果连翻墙都没有办法(比如,你家的运营商是个渣渣),那用 必应 也还行。

搜索内容

  1. 报错日志的关键字,越具体越精确越好。举例:error 是一个很泛的词,而 unexpected token < 或者 permission denied 是一个比较精确的描述。
  2. 加上你使用的语言/框架/库 作为限定范围,别找 JavaScript 的错误跑 Java 去了。

搜索技巧

  1. 请用英语搜索(尝试用一切方法用英语描述你的问题)。我并没有崇洋媚外的意思,但是我个人认为,在目前比较流行的技术(比如,React)上,国外的速度还是要比国内快一点点的。国内的大牛作品,也多少建立在阅读(或翻译)国外博客/代码等等之上的。况且我们还有大 Stackoverflow。
  2. 如果遵循了第一点,你会摸索到很多第2方法,比如直接上 Stackoverflow, 直接上 Github,直接查源码,直接订阅博客, etc.

这方面其实我也不是很出色(可能是因为我的问题用关键字就已经能查到了),所以推荐 @cee 同学的 一篇文章,里面有详细的描述。

Have fun searching!

3. 如果还没有搞定(如果你看到这里)

请再次检查这是不是自己挖的坑。
或者把椅子拉后一点,喝口水,认真检查一次报错日志,理一理思路。
尝试一下用 小黄鸭调试法
准备问问题。

4. 问一个高质量的问题。

在说这个之前,我要搬出伟大的 Eric Raymond 的 「提问的智慧」

如果你看完了,你就会说:早知道我就直接看这个了,还要听你胡扯!(如果你没看完,可以看完再回来说这句话)

但是我还是想说下我的看法。这是我对自己提的问题的要求:

  1. 要有一个详细的,具体的标题。一目了然,方便导航,方便搜索,方便老司机带你飞;
  2. 记录你在问之前做过的 debug,排除杂音;
  3. 在解决之后修改题目,标记为【已解决】,再补一个解决方案;
  4. 要懂得 say thankyou

而一个好的提问究竟是怎样的呢? 我找到了一个挺不错的 栗子

有一个童鞋提出,问问题只是“顺便问”,这样能省下自己的时间。我想让大家一起思考的问题是:假如你是一个老司机,很会指路,如果让你重复的指很多次一样的道,话过三巡也会腻烦的吧?

Why the fuck

我觉得还是会有童鞋说:“我很急,我需要一个快速的答案!” 我的理解是:

  1. 你没有安排好你的时间。非要到死线前才来要求生产力,是一种上了茅坑不冲屎,再上同样的茅坑屎还在的行为。

    Since you didn’t debug by yourself, you never know what the hell is behind the scene.

  2. 你很懒,懒到让别人帮你买单。

Q.E.D