Asking the right question is frequently more than halfway to the solution of the problem. ----Heisenberg
人从降生伊始,除了刻在我们基因里的本能,其它额外的知识都需要我们后天的学习。学习就一定会遇到问题,但又不可能所有的问题都靠自己解决。所以就会提问。小到"1+1=?",大到"我们从何而来,又要到何处去?"。人类文明就是在这不停的提问--解答循环中先前迈进。
扯远了,作为一个程序员,无论是从事哪个方向,每天都会被无尽的需求,Bug,旧代码围绕着,也会遇到各种各样的问题。而你的价值也就在于解决这样那样的问题。然而,就算再厉害,也总会遇到自己搞不明白的问题,知识后就要去问,而如何去问,我今天就要说说这个东西。
我的经历
初中的时候好像还不怎么喜欢问问题,到了高中一到下课就开始追着各科的老师问。大学里,就问隔壁寝室的大神。刚上班的时候,感觉自己什么也不会,学校学的和工作用的完全不同,就开始揪住老员工(大多数就比我大一届)不停的问,自己工作也很多年了,也从初出茅庐，算上个半吊子老员工了。但是计算机这行，知识是永远学不完的。前一段时间深感C++的基础不够好,想补一补。正好我身边也一直有一位C++牛人，之前也一直帮助我,所以补C++,我就边学习,边向他请教。而在这段时间的过程中,再回首这几年来的经历。有了点思考。遂有此文。
本人主要想讨论三个方面：
- 问题提炼
- 如何提问
- 总结问题
下面就一个一个来说说我对这些问题的看法,当然和那些心理学家,认知科学家以及业界的大神牛人们比,此文完全是班门弄斧了。所以以下观点,仅是我个人总结的看法,仅供参考。
问题提炼
可能会有人觉得，下面的内容都是没用的废话，有问题就是有问题，还能怎么样？问不就得了。这也确实是我一开始养成的习惯。比如看书遇到了自己没有第一时间搞明白的地方,碰巧自己身边又有可以请教的人,想都没想,拿着书就跑过去问。但可能这个问题很简单，只是你没认真,漏看了一句话,一段字而已。所以有时候你所谓的问题,它真的是个"问题"么？不妨再你再遇到问题之前照下面的几点来试试,看看是不是能解决了你的问题：
1.如果是看书或者文章时候没有搞懂,先仔细的再读几遍原文,看看是不是自己漏看了什么内容,有些好书经常会提示你看此处内容时候要结合XX章节的内容,这种情况下的"问题",实在是有点犯二,就像上学时候考试,条件都没看全,就开始写答案。
2. 如果你翻看的是别人代码,特别是维护别人的代码,一时间没看明白(有时候自己写的代码,过一段时间看也可能会看不懂)。第一时间是去找看注释，找文档，或者在上下环境里有没有类似的内容。如果都没有,不妨打个断点,调试看看,是不是能从堆栈和变量的监视里看出些端倪。
3. 兄弟,抬头看看旁边你收藏的落满灰尘的书堆里,是不是有什么可以参考的好书呢,我想程序员里一定有不少人和我一样是买书狂魔(上班后好多了,比较有选择),买了一堆,却没看几本,工位上，床头摆上几本，有问题了,不妨翻翻。
4. "度娘","谷哥",绝对算是程序员的好帮手了,而不可否认的是程序员这个群体都是思想很open,很喜欢share的。虽然都说理科生的表达能力不行,但也不乏pongba这种文章好,技术也好的牛人。所以,作为生活在互联网时代程序员,这么大在资源库没有机会不去使用。当然,搜索引擎也不可能知道所有的问题,你项目鬼斧神工般的代码,不可能网上也有那么一份(除非...)。所以搜索之前,先归纳一下自己的问题。也不要好高骛远,什么事情非要翻山越岭跑去Google一下,显的自己很有水平。百度有时候也能解决你的"小问题"。再有就是如果搜索出来好的结果不妨把网页添加到收藏里。这样下次再遇到类似问题就不用再查一遍了。
5. 如果上面的几个方法，你依然找不到想要的答案。自己思考思考，动手敲敲网页(或者书)上的代码,纸上得来终觉浅,绝知此事要躬行。自己写几个例子,跑几遍看看结果。动笔在纸上演算演算。也许这个过程中就把问题搞定了。甚至有时候书上写的,网上写的也不一定就是对的。只有自己试过了,思考过了才知道。
...
上面这些只是个引子,每个人都会有自己遇到问题的一套解决方法。总之,绝不可一开始就立刻去问别人。要确确实实是自己对"问题"思考过了,尝试过自己所能的解决办法依然没有结论的。那么到了这一步就可以去请教别人了么？不,还不够。这个"问题",现在还只是你自己所谓的"问题",你可能知道你自己想要问什么,但是你这个"问题",明白的传达给被问的人。你是有过这样的感觉,你脑海里知道这个问题是什么样的，但是在你向别人描述这个问题的时候,确怎么也表达不明白,如果这时候被你请教的人再反问你几个问题,你可能就开始语无伦次了,把自己都搞蒙了。这是个很严重的问题。自己有"问题",还不行还要把它提炼成别人听得懂的"问题"。如何做呢？这倒没有什么通用法则,被提问的人不一样,可能注意的地方也不一样。下面谈谈我自己认为的一些小方法：
1.要像前面提到的那样,一定要自己认真的思考过了,尝试过了。因为只有这样你才把问题本身弄清楚了,如果自己都没明白问题是什么,怎么指望别人能给你答案。您别笑,我以前就不止一次的这样去问过别人。
2. 如果你这个问题有对应的代码或者文字,图片,哪怕是相关联的文章。都找出来,标记出来。所谓"一图胜千言"。有这些可以参照的东西。别人会更容易理解你的问题。甚至一看就知道你要问什么。
3. 先自己模拟一下给别人描述自己的问题,通过书写(网络提问)或者语言来讲给自己。把自己当初被提问的人,看看自己能不能听明白,看明白。这可不是什么人格分裂。我不信你平时没干过，比如你要去见什么重要的人,你估计一定会自己演练几遍。而且在给别人描述问题的过程中,你很可能会找到灵感，甚至找到答案。
### 没什么固定的方法,目的很简单,就是为了让别人能更好的理解你的"问题"。有了上面这些过程，你不仅自己对问题理解的更深刻了,也会再接下来提问的过程中减少了浪费掉的时间。好吧，还是搞不定,该去请教请教牛人了。如何提问
"问题"已经有了，但是怎么去问，也是有注意的地方。我们提问无非两种方式:网上提问,向身边的人提问。这两种方式还是很不同的:
网上提问,一般是并不指望能第一时间得到答复的。国内的话提问的地点无非就是贴吧，CSDN，或者一些Blog和论坛。国内专业向的技术站点是真心不多的。OpenGPU算是一个。当然了,限于工作方向，肯定还有好站点是我不知道的。对于很多大学生和自学者来说,身边没有可以探讨的人,网络无疑是他们唯一发问的地方,不过有些地方还是提一些小建议，让你的问题更容易获得答案。
1.不要说大段的废话,"我从小家贫,XX学历毕业,自学至今"。朋友这里不是中国好声音,也不是希望工程。赶紧挑干的说。把问题描述的言简意赅，写完了自己读读，有没有错字连篇，思想混乱。先让自己看明白。
2. 最好配上图,配上代码。如果提问的站点没有格式化代码的功能的话,不要直接把代码乱七八糟的发上来,看到这种东西就不想继续往下看了。你可以把代码发到一个网盘上,然后留下链接。说到图,经常会看到网上有人把一个报错图片发上来,就问怎么解决,连点描述都没有,让大家帮着你瞎猜么？至少解释一下相应的上下文。
3. 不要抱怨,很多人提问,没人回答就摆出一副很生气的样子,说"没人回答算了","都不爱帮我",甚至更不好的话。不妨看看是不是自己的问题没有描述清楚，你真的确保别人能明白你在问什么么？而且谁也不是大闲人，有时候耐心点等上一段时间。要谦卑些,不要请教别人问题还高高在上。
4. 如果国内的站点解决不了你的问题,不要害怕去外国站点用英文提问,只要你的英文不是太差,几本的简单语法和专业词汇都没问题,最好再配上些图片。老外是能明白你的意思,就像你看老外说蹩脚中文,你也依然可以理解他要说什么。而且你只要专业词汇别用错了。语法差一点也是可以的。Just Ask！
...
另一个方式就是去问身边的牛人了,这在刚上班的时候最常见了,一般公司或者上司都会指定一两个人来指导你,不会的东西可以去请教他们。在网上提问,你可以没什么顾忌,但与人打交道就是另外一回事了。
1.不要老是拿小问题去问,这也是我自己刚上班的一个问题。遇到一点不会的就屁颠屁颠的跑过去问这问那。新人我还可以理解,如果工作几年了还这样确实就不好了。而且就算是新人如果老是去问太没营养的问题，别人可能也会觉得你是真有"问题"。所以提问之前要像第一部分说的对问题进行提炼。是不是这个问题值得一问。
2. 找准提问的时机,即使你真的需要提问,也要看机会是否合适,平时上班大家都在忙,可能正在思考一个问题,突然有了灵感,突然被你打断,又不好意思拒绝你,长此以往,对方可能就很不愿意再和你讨论问题。所以去提问之前先观察观察对方是否正好有空闲,如果可以的话,不妨把问题留在午休或者下班之后去问。
3. 适当的称赞对方,这不是鼓励你去逢迎别人,别人解答了你的问题，给了你启迪,去称赞一下对方,有什么不好呢。很多人在网上问问题得到了解答,往往都会留言称谢。而到了现实中却开始不好意思，吝啬自己的称赞了。这完全没必要。而且合适的称赞也可以让对方多少感觉上一些内心上的满足。以后可能会更愿意回答你的问题。这是自然的，程序员往往更是如此。谁都喜欢收到别人的称赞,就像我写Blog,如果别人在留言里说文章对他有帮助或者一些感谢的话。我小小的虚荣心也得到了些许满足。别人都是不求回报的去帮助你，为什么不能不能给一句称赞呢。
4. 问问题的过程,也是一次沟通的过程,所以良好的沟通技巧,也同样适用于提问。
提问的好坏对结果影响很大,比如网上一个好的问题,有时候即使没有答案，你看了也会对你很有启发。有一种"我怎么没有想到这个问题"的感觉。不管怎么样,你的问题可能都已经找到了答案。也许并不是你最满意的答案,但是至少是可以接受的。到这里问"问题"这个过程也可以结束了,但是如果你一个喜欢探求的人,那么应该需要第三部分了。
总结问题
我们的问题,找到了答案,好像解决了我们的疑惑。拿过去在代码里用好像也没出现问题,万事大吉了。那现在不妨回头思考思考,这次问答的旅程,是不是还有什么可以梳理的地方。如果你耐心仔细的去探究，也许你可以收获到的往往不只是你提出的问题而已。
1.对答案本身的分析，也许已经得到了答案，但是这个答案也许并不是最优的,仔细的再结合着答案思考一下问题,是不是还有更优的解。
2. 思考一下为什么回答你问题的人能想到答案。是不是你也知道想出这个答案所需的知识,但是你却没有想到,回答你问题的人他是怎么样的思考过程。这种思考过程是最为重要的。pongba在他的《暗时间》里就举了学校里教数学的例子,教科书只告诉你XXX想到了这个定理,给出了那个证明。却不会告诉你那些数学天才们是如何想到的。而如果答案用到了你没有了解过的知识，那么就应该去相应的查缺补漏。
3. 有时候回答问题的人会给你留一些好站点的链接，或者去让你参考什么什么书，这些一定要记下,因为在这个信息爆炸的时候,这些东西都是他们自己总结出来的精华。为什么不吸收下来的。
### 一个问题,问好了双发受益,尤其是在互联网上这一问一答可能让更多的人受益。而问不好,则完全实在浪费时间。有时候不只有解答问题能体现一个人的水平,提出一个好问题也可以是一个很有水平的事情。文章开头的那段引言翻译如下：
提出正确的问题,往往等于解决了问题的大半。--海森堡
