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