-
-
[转帖]提问的智慧——新人快速提升指南
-
2016-9-14 07:56
-
链接：http://iosre.com/t/topic/2990
新人不仅仅是指刚刚加入论坛，或者刚刚开始学习逆向工程的人；我们所有人在不擅长的领域都是新人，都应该以“Stay hungry, stay foolish”的心态来面对新鲜事物。新人不丢人，一直当新人才丢人！当我们进入一个陌生的领域时，如何快速成长呢？我认为主要有这么几点：
0 总则
自己去寻找答案，在寻找答案的过程中碰到了问题，再寻求帮助。而不是直接问别人要答案。
1 擅用搜索
上不了Google？百度一下“谷歌镜像”，就可以找到最新的谷歌镜像网站，与直接谷歌搜索无异；
如果是科学上网就更方便了。
当然，论坛里也可以方便地全站搜索
或者用Google提供的站内搜索，比上面Discourse自带的全栈搜索更好用哦~推荐！
实在搜不到，再发帖问；并且在问题里把你搜了什么，搜不到什么都描述出来，即能辅助别人判断问题，又可以为后来人作参考，何乐不为？
2 怎么问问题
先看看：
你会问问题吗？
在工作和生活中，总是会有很多人问题我很多技术方面的问题。有一些时候，问问题的和答问题的总是会有一些不爽的事情发生。如下面的几种情况：
比如：“我的电脑老是蓝屏，怎么办？”，通常这样的问题90%以上的回答是：“重装吧”。这让问问题的人感到很沮丧，但你不能不承认那不是答案。而且有时候让人无法解答，比如：“我的makefiel出错了，你帮我看看我的makfile”，我通常会非反问，报了什么错吗？
另一种情况是，回答问题的人首先先对问问题的人的抱怨，你问的问题就不对，或是，你问的这个问题是什么意思，而导致问问题的人却在不停地解释，结果花了好长时间来讨论问题本身是什么。
还有一种情况是，问的问题太简单了甚至太白痴了，比如你自己试一试或是读读文档就知道了的问题，或是问这个问题直接表明了你的无知或是懒惰。这种问题会相当影响别人对你的印象。
第四种情况是，提问者滔滔不绝，扯这扯那，讲了一大堆，听得听累了。最后都不知道你要干什么。
所以，怎么去问问题，怎么问一个好的问题，是一个很重要的事。你提问的技术直接关系到了你是否能够很快得到你满意的答案。
这里有一篇文章推荐给大家《How To Ask Questions The Smart Way》，中文版在这里《提问的智慧》，我把其中的几个亮点总结如下：
提问前先自己尝试查找答案，读读文档、手册，看看有没有相似的问题，看看那些方法能不能帮你解决问题，自己去试一试。如果你是程序员，你应该先学会自己调查一下源代码。（不然，人家回答你的一定是——RTFM – Read The Fucking Manual）这样的问题很多。我有时候很不愿意回答这样的问题，因为我觉得问问题的人把我当成了他的小跟班了。
提问的时候，找正确的人或是正确的论坛发问。向陌生人或是不负责的人提问可能会是很危险的。不正确的人，会让你事倍功半。如果你问Linux的人Windows太慢怎么办？他们一定会让你把Windows删了装Linux去的。
问的问题一定要是很明确的，并且阐述你做了哪些尝试，你一定要简化你的问题，这样可以让你的问题更容易被回答。对于一些问题，最好提供最小化的重现问题的步骤。
你一定要让问题变得简单易读，这和写代码是一样的。只有简单易读的邮件，人们才会去读，试想看到一封巨大无比的邮件，读邮件的心情都没有了。而且，内容越多，可能越容易让人理解错了。
你问问题的态度应该是以一种讨论的态度，即不是低三下四，也不是没有底气。只有这样，你和你的问题才能真正被人看得起。要达到这个状态，不想让别人看不起你，你就一定需要自己去做好充足的调查。问题 问得好的话，其实会让人觉得你很有经验的，能想到别人想不到的地方。
不要过早下结论。比如：“我这边的程序不转了，我觉得是你那边的问题，你什么时候能fix？”，或是“太难调试了，gdb怎么这么烂？！”。当你这么做的时候，你一定要有足够的信息和证据，否则，你就显得很自大。好的问题应该是，“我和你的接口的程序有问题，我输入了这样的合法的参数，但是XX函数却总是返回失败，我们能一起看看吗？”，“我看了一下gdb的文档，发现我在用XXX命令调试YYY的时候，有这样ZZZ的问题，是不是我哪里做错了？”
说的就是你：不要再提x-y问题啦！
X-Y问题
对于X-Y Problem的解释如下：
1）有人想解决问题X
2）他觉得Y可能是解决X问题的方法
3）但是他不知道Y应该怎么做
4）于是他去问别人Y应该怎么做？
简而言之，没有去问怎么解决问题X，而是去问解决方案Y应该怎么去实现和操作。于是乎：
1）热心的人们帮助并告诉这个人Y应该怎么搞，但是大家都觉得Y这个方案有点怪异。
2）在经过大量地讨论和浪费了大量的时间后，热心的人终于明白了原始的问题X是怎么一回事。
3）于是大家都发现，Y根本就不是用来解决X的合适的方案。
X-Y Problem最大的严重的问题就是：在一个根本错误的方向上浪费他人大量的时间和精力！
示例
举个两个例子：
Q) 我怎么用Shell取得一个字符串的后3位字符？
A1) 如果这个字符的变量是$foo，你可以这样来 echo ${foo:-3}
A2) 为什么你要取后3位？你想干什么？
Q) 其实我就想取文件的扩展名
A1) 我靠，原来你要干这事，那我的方法不对，文件的扩展名并不保证一定有3位啊。
A1) 如果你的文件必然有扩展名的话，你可以这来样来：echo ${foo##*.}
再来一个示例：
Q）问一下大家，我如何得到一个文件的大小
A1) size = ls -l $file | awk ‘{print $5}’
Q) 哦，要是这个文件名是个目录呢？
A2) 用du吧
A3) 不好意思，你到底是要文件的大小还是目录的大小？你到底要干什么？
Q) 我想把一个目录下的每个文件的每个块（第一个块有512个字节）拿出来做md5，并且计算他们的大小 ……
A1) 哦，你可以使用dd吧。
A2) dd不行吧。
A3) 你用md5来计算这些块的目的是什么？你究竟想干什么啊？
Q) 其实，我想写一个网盘，对于小文件就直接传输了，对于大文件我想分块做增量同步。
A2) 用rsync啊，你妹！
这里有篇文章1说明了X-Y Problem的各种案例说明，我从其中摘出三个来让大家看看：
你试图做X，并想到了用Y方案。所以你去问别人Y，但根本不提X。于是，你可以会错过本来可能有更好更适合的方案，除非你告诉大家X是什么。
— from Re: How do I keep the command line from eating the backslashes? by revdiablo
有些人问怎么做Y，但其它他想做的是X。他问怎么做Y是因为他觉得Y是最好搞定X的方法。 于是大家不断地回答“试试这个，试试那个”来帮助他，而他总是在说“这个有问题，那个有问题，因为……”。基本不同的情况，其它的方案可能会更好。
— from Re: Re: Re: Re: regex to validate e-mail addresses and phone numbers by Limbic~Region
X-Y Problem又叫“过早下结论”：提问者其实并不非常清楚想要解决的X问题，他猜测用Y可以搞定，于是他问大家如何实现Y。
— from <Pine.GHP.4.21.0009061210570.8800-100000@hpplus03.cern.ch> by Alan J. Flavell
其实这个问题在我之前的《你会问问题吗2》里提到的那篇How To Ask Questions the Smart Way中的提到过，你可以移步去看一下1。
所以，我们在寻求别人帮助的时候，最好把我们想解决的问题和整个事情的来龙去脉说清楚。
一些变种
我们不要以为X-Y Problem就像上面那样的简单，我们不会出现，其实我们生活的这个世界有有各种X-Y Problem的变种。下面我个人觉得非常像XY Problem的总是：
其一、大多数人有时候，非常容易把手段当目的，他们会用自己所喜欢的技术和方法来反推用户的需求，于是很有可能就会出现X-Y Problem – 也许解决用户需求最适合的技术方案是PC，但是我们要让他们用手机。
其二、产品经理有时候并不清楚他想解决的用户需求是什么，于是他觉得可能开发Y的功能能够满足用户，于是他提出了Y的需求让技术人员去做，但那根本不是解决X问题的最佳方案。
其三、因为公司或部门的一些战略安排，业务部门设计了相关的业务规划，然后这些业务规划更多的是公司想要的Y，而不是解决用户的X问题。
其四、对于个人的职业发展，X是成长为有更强的技能和能力，这个可以拥有比别人更强的竞争力，从而可以有更好的报酬，但确走向了Y：全身心地追逐KPI。
其五、本来我们想达成的X是做出更好和更有价值的产品，但最终走到了Y：通过各种手段提升安装量，点击量，在线量，用户量来衡量。
其六、很多团队Leader都喜欢制造信息不平等，并不告诉团队某个事情的来由，掩盖X，而直接把要做的Y告诉团队，导致团队并不真正地理解，而产生了很多时间和经历的浪费。
所有的这些，在我心中都是X-Y Problem的变种，这是不是一种刻舟求剑的表现？
附2个案例：
不好的问题案例
好的问题案例
好在哪里，不好在哪里，大家很容易就可以看出来。想要自己的问题得到更好的解答，就体现出你提问的诚意；提问的诚意如何体现？在问题里体现出你做过的努力。
阿里云助力开发者！2核2G 3M带宽不限流量！6.18限时价，开 发者可享99元/年，续费同价！
|
|
|---|---|
|
|
|
