经常有人问我问题，我也经常需要请教别人问题。我认为越真实扼要的描述，越有助于别人理解。

不要首先描述推断

很多人一上来就问一个让人不明所以的问题，其中的信息80%源于他们自己的推断，同时对真正的需求闭口不谈。

  • 常见句型一：我已经照着教程每一步做了，为什么还是不行？
    • 这样说，只能让人觉得，教程错了，或者是过时了，软件更新换代很快，很多资料都不兼容新版本，但也有很多东西是可以控制版本的，如果环境控制好了，做个demo依然是ok的。
    • 所以，是人做错的可能更大，而这时的信息对找出错误却毫无帮助。
    • 请直截了当的描述使用了什么教程，走到了哪一步，出现了不同的结果，错误信息是什么，你期望的是什么。最后再是你的推断，比如教程错了，不兼容了。
  • 真实案例一：如果我的程序core dump了，那么容器会消失吗？
    • 容器这个词很难定义，要是说运行时的状态，那很显然是消失了，也就是docker ps看不见这个容器，ps aux也看不到这个容器相关内容。
    • 如果指硬盘上的信息，那是不会消失的，也就是用docker ps -a能够看见。
    • 最后这个同学的问题是，在启动容器时使用了–rm参数，使得容器停止时删除了硬盘上内容。
    • 可以发现，他问的第一句话没有能提供准确的信息，甚至有很多噪音，比如core dump。
    • 遇到问题应该冷静描述过程和期望。
    • 略好一点的问法：容器停止时，会被删除吗？
    • 但这一点也不make sense，要是停止就删除，还要ps -a做什么？而且这个问题可以搜索得到答案，不是一个值得拿来challenge别人的问题。拿出来问的问题，应当是不太好说清楚，不能搜索到完全类似的情况的。
    • 觉得很nice的问法：我用命令docker run --rm -v xx --net xx -p xx xx启动了一个容器，容器停止后不见了，docker ps -a找不到。
    • 这样能让更熟悉某个东西的人，更快地帮助你解决问题。

需求优先

在公司经常会因为不知道怎么实现一个需求，然后去问一问同事，这时候很可能一开口就是，”如果我使用xx技术，可以实现yy效果吗？”。这有几个问题。

  • 陷入了非常细节的部分，某个技术能否实现某个事情，正是你这个程序员要做的事情，你做出来之前，那就是无法实现，做出来了，那就是落地成功了，所以问有什么用呢？
  • 也许你是想要确认你的思路，那应该更准确的描述，描述你打算怎样去实现，直接说出你的整个设计，让高手听听是否有问题。
  • 没有给高手提出更优解的机会，因为没有描述原始需求。
    • 举例：写一个程序，有两个输入a、b，一个输出c。现在做测试的时候，你找到了输入a，但是没有输入b，可能是因为测试环境里没有输出b的程序，可能是因为公司的防火墙，也可能是因为你不知道有。那很可能找到一个人，开口就问，你能不能setup一个输出b的程序给我？
    • 别人也不知道你拿来做什么，如果他不多问，可能他就真的去帮你找了。但实际上，你需要的只是一个输入，有现成的也可以work。为什么不说得更详细一些呢？
    • 我的程序做测试，需要两个输入a、b，才能输出c，我已经通过xxxx找到了a了，输入b应该怎么办？（同时还可以说说为什么不能用和a同样的方法实现b）。
    • 而且，能更好地让别人知道你在做什么，有时候可能你的方向都错了，现实是，你这个程序应该输入a和d就可以生成c，而不是a和b，那这时候就是错误的方向越走越远。

向高手迈进

最后想说的一点是，多问问自己，多搜索，多过几遍流程。
有多余时间的话，阅读所有相关手册，而不是出了问题大海捞针，首先熟悉操作手册，能够免除非常多的问题，比如容器rm参数，看懂了就不会有那个问题。
这一点我自己做的也不是很好，有时候喜欢从mentor那里得到一个quick answer，有能够让搜索引擎听懂的描述，也不愿意去搜索结果中找答案。这个得慢慢熟悉情况，多尝试了。
与君共勉。