在软件开发的过程中, 问问题是一个非常重要的技能. 根据我同事的反映, 我在这个方面比较擅长. 以下是我的一些经验技巧, 现在和大家分享一下.
在以前, 我总是问出质量很差的问题. 要么就是提出一些让别人无法回答的问题, 要么就是提出一些在 Google 上或者代码库上很容易搜到答案的问题. 那时候我并不想这样, 但是却一直这么做.
下图显示的是一些提问的策略. 这并不意味着你不这么做就问不出一个好问题. 而是说, 这些是一些好的建议, 能帮助你表达出你想要的, 最终帮助你解决问题.
什么是好问题?
我们的目标是将问题简化为容易回答的概念性技术问题. 我经常发现, 我身边的人掌握着我正需要的技能, 但是他们并不知道如何向我解释.
如果我问出一个好问题的话, 这样别人也可以有效地向我解释, 并且可以引导他们给我讲述一些我感兴趣的知识. 那么让我们开始吧.
表达出你知道的
这是我最喜欢的提问技巧! 这种类型的问题一般是以下的形式.
1. 表达出你已经知道的
2. 然后问 "对么"
举个例子, 最近我和一个人 (一个非常棒的提问者) 讨论了网络. 他说他了解链递归 dns 服务器. 这是错误的, 事实上没有链递归 dns 服务器这种东西. 所以他表达出了他的理解, 这样我们就可以很容易阐述我们的观点.
前段时间我对 rkt 很感兴趣, 但是我不理解为什么 rkt 在运行容器的时候比 Docker 占用更多的磁盘.
如果我这么问, 效果肯定不会那么理想. 我对代码执行的方式有一点理解, 所以我给 rkt-dev 写邮件的时候我问道:"为什么 rkt 存储容器图像不同于 Docker"?
写下我对 rkt 和 Docker 在硬盘上存储容器的理解
想出了几个原因, 我认为他们可能会按照这样的方式设计
然后问, 这样对么
我收到的回答恰到好处地回答了我的问题. 用这种方式表达出我的问题花费了我一些时间, 但是这些时间是值得的, 因为我更理解这个问题了.
往往表述出自己的理解是不容易的(你得花时间考虑你知道的然后表达出你的想法). 但是这是非常有效的, 不仅仅是对你, 也是对你问的人.
问出答案是事实的问题
我以前总问一些非常模糊的问题, 比如 "SQL 中 join 如何使用". 这是一个非常糟糕的问题, 因为 join 有很多种用法, 回答者不可能知道我对那种感兴趣.
我喜欢问一些答案是很直白的事实的问题. 举个刚刚 SQL join 的例子, 答案是一个直白事实的问法是:
Join 两个大小分别是 M 和 N 的表的时间复杂度是多少? O(NM) 还是 O(NlogN) + O(MlogM)
Mysql 数据库会对关联的列先排序在做关联操作么?
我知道 Hadoop 有时使用哈希关联, 其他数据库也会采用这样的策略么?
如果我需要将一个索引的列和非索引的列关联起来, 我需要先对非关联的列进行排序么?
我们问这么具体的问题, 回答者不一定知道答案, 但是他们一定知道我的关注点是什么. 起码他们知道我并不想知道数据库表中 join 的使用方法, 我想知道其中细节和实现算法.
主动表达出你不明白的地方
在很多情况下, 别人给我讲解一些知识的时候, 有些概念我并不理解. 举个例子, 别人给我我讲解数据库相关知识的时候, 可能会说 "我们用 Mysql 的乐观锁来...". 我并不知道乐观锁是什么, 因此这是询问的最佳时机.
适时打断别人, 并提问 "这是什么" 也是一个重要的技巧. 我认为这是一个自信的工程师必备的技能, 而且是一种成长. 我经常看到很多高级工程师频繁地提问. 我觉得如果你掌握了技巧, 这就很容易做到.
做的多了, 我让别人解释的时候也会越自然. 事实上, 如果我在给别人讲解的时候, 如果别人没有提问, 那么我会认为他们没有认真听.
给解答者提问事实上不仅能帮助他们巩固知识, 还能帮助他们找到自己的不足. 我在提问的时候总会问一些他们也不知道的问题, 而回答者也会大方地告诉我, 他们不知道.
识别不理解的地方
在我刚开始做这份工作的时候, 我是在数据小组. 当我询问我们小组需要什么知识的时候, 我的听到 Scalding 了一些非常棒的关键词: Hadoop,Scalding, Hive, Impala, HDFS, zoolander 等. 这些关键词中我只听说过 hadoop, 其他的关键词并不了解. 可能它们中有的是内部项目, 有的是开源项目. 所以, 我首先做的事情是请人给我解释这些关键词的含义并梳理它们的关系. 我可能会问类如下面的问题:
HDFS 是一个数据库么?(不, 它是一种分布式文件系统)
Scalding 会用到 hadoop 么?(是的)
Hive 会使用到 Scalding(不会)
由于术语很多, 我便将这些术语记录成一个小字典. 对这些术语的理解能帮助我问出更好的问题.
做一些调查
当我输入上面的 SQL 问题的时候, 我在 Google 上搜索了 "sql 中 join 如何实现" 这个问题. 我点击了一些链接然后发现, 这些链接中有的包含排序, 有的包含哈希连接. 然后我就可以提出更加有针对性的问题. 在 Google 上做一些搜索也能帮助我问出更好的问题.
因此, 我也理解了别人为什么总说, 问别人问题前先 Google. 但是这也分情况, 有时候我和别人共进午餐, 而且我对他的工作非常感兴趣, 我就会问他一些入门的问题. 这样做也收到了不错的效果.
做一些调查也确实起到一些作用. 在经过一系列调查之后问出一个棒棒的问题的过程也是非常有趣的.
决定问谁
我这里谈到的问问题大多是问同事, 这也是我经常做的.
然而, 我问他们问题之前总是有以下的考虑.
现在问他方便么?(可能他正在处理一些棘手的问题)
这个问题是否值得问他呢?(可能他花 5 分钟就能帮助我省下 2 小时)
我问的问题会花费他多长时间呢? 如果我有半个小时的问题要问, 我就要和他先预约一下, 如果只是一个简单的问题, 我就会立刻问他.
找他来回答是否合适? 我认为问一个专家一些入门的知识是不合适的, 最好是选择一个没那么专的人. 他刚好能回答我的问题, 而且也能帮他展示他的知识.
在这方面我做得也不是很好, 但是问问题前考虑这些是有用的
此外, 我通常花更多的时间询问我周围的人 - 几乎每天都和他们讨论, 我通常可以很容易地问他们的问题, 而且我们工作背景一样 可以很容易地给我一个有用的答案.
使用 ESR 问出聪明的问题是一个非常流行的文档(这个文档开篇就将我们定义为失败者). 这个文档是关于在英特网上问陌生人问题的. 在互联网上问问题是一个非常有用的方式, 但是也增加了问问题的难度, 问的好了自然是能得到一些信息, 问的不好则会无人问津. 由于回答问题的人不知道你当前的处境, 因此准确表达出你想要的非常重要. ESR 这个文档中的观点我是不很赞同的, 但是其中的一章 "如何有效回答问题", 非常棒.
提出能揭示隐含信息的问题
一个更高级的技巧是问出能揭示隐藏的假设或知识的问题. 问这样的问题有两个目的. 第一个是获得答案(有的信息有些人知道, 有些人不知道); 第二是分享一些隐含信息.
Etsy 的汇报简化指南中的 "提问的艺术" 是针对这一问题非常棒的导论. 这本书用一些事例来讨论问问题的方式. 下面列了一些导论中的问题:
当你怀疑这种类型的故障发生时, 你会看到什么?
你如何判断这样的情况是正常的呢?
你怎么知道数据库当掉了呢?
你怎么知道这是你要找的团队?
这些类似的问题 (看起来很基本, 但实际上并不明显) 在某些权威人士口中问出的时候会发挥巨大的作用. 当一个经理或高级工程师问一个基本但重要的问题, 如 "你怎么知道数据库失败了", 我会感到非常高兴, 因为它为水平低一点的人提供了以后提出相同类型的问题的空间.
回答问题
在我最喜欢的 André Arko 的帖子中, 他总说到:
当你了解了所有的问题并提出新的请求的时候, 尝试回答一些你力所能及的问题. 当你注意到一个别人问的问题你刚解决, 或者刚在文档中看到, 那么不要吝啬你的答案, 这不会花很长时间.
当你开启一个新项目的时候, 回答一些做和你之前项目类似项目人的问题是一个非常好的巩固知识的办法. 当我回答一个问题的时候, 我总是担心我会回答错. 但事实上我的回答总是对的, 然后我对相关的知识更加理解了.
问题的作用非常巨大
对社区来说, 好问题的影响力是巨大的. 前一整子, 我在 Twitter 上问了许多关于 CDN 的问题, 然后我用 "CDN 不只是为了缓存" 来回答. 很多人告诉我, 他们非常喜欢这个博客. 这就意味着, 我问的问题不止帮助了我, 还帮助了许多人.
许多人喜欢回答问题, 我认为, 好问题可以让人非常困惑, 然后主动参与到讨论当中.
以上为译文
本文由阿里云云栖社区组织翻译.
文章原标题《How to ask good questions》, 作者: Julia Evans, 译者: 爱小乖
来源: http://www.jianshu.com/p/a95b4b9c2bd1