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

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

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