在 segmentfault 泡了一段时间了，看了很多提问，也回了一些，一般就自己所在的开发方向相关的问题会点进去看，但是有很大一部分是点进去，看一眼就叉了，其中一些是自己解决不了的，更多的是不懂题主在问什么、或题主明显就想要个答案让答主填个空而已、或这个问题搜一下就可以解决的、或代码上百行贴出来的......总之，这些问题“问题”本身有各种各样的“问题”！
梳理了一下，当我们遇到问题，有想提问的冲动时，我们应该怎么做，希望有心在开发的不归路上走到黑的程序员们能掌握提问的艺术，因为技术的发展快过了你的学习能力，作为开发者是必然会和问题相伴一生的。
全文分4个部分，见下图，如果觉得自己是会独立思考，是会搜索的，是态度端正的旁友，只是不知道怎么组织一个好提问的，可以直接跳到第3部分（组织你的提问），不过我建议还是从头浏览到尾，也不会花太多时间。
一. 遇问题先搜索
很多很多时候，你的问题别人已经遇到过了，所以别人可能提问过了、可能小结过了（也许在某一篇博文里）、可能在技术文档里提到过的，而其中大部分相关的内容，搜索引擎足以帮你找到相关的内容。
1. 态度——别做伸手党！什么是伸手党？
没问过搜索引擎、没查过技术文档、没自己的思考、没自己尝试解决过，而只是想要最后的代码，答主给了思路，还要求代码！
总之，他们只是需要有个人能帮他们填个空好交差，因为这样最安逸。
对这类人，微笑，再见。（而且往往这样的提问，会被踩）
2. 先搜哪些东西？
首先，大家肯定是想到搜索引擎，对的，搜索引擎能帮你搞定大部分的事，甚至如果花在搜索引擎上的时间超过了你实际码代码的时间，那就是很流行的“面向搜索引擎编程”。
首选Google，至于梯子的话自己去搞，为什么首选google，因为喜欢不需要理由，一定要有的话就google有一句话“Don't be evil”，国内某娘我有时查一下，头条还是外包广告。
再者，如果是针对某一项技术的问题，可以去翻他们的在线文档，官方文档永远是最靠谱的，不过要注意版本。比如，"jquery的ajax请求怎么设置同步没用了，以前还有用"，这样的问题去看下文档就知道了。
最后，你要提问的话，还有提问社区的很多类似问题，可以先搜一下。国内的segmentfault，国外的stackoverflow，上面都有很多优秀的问题，很多问题最后是“月经问题”，就是提问前不搜直接问的人太多了。
总之，遇到问题，先去找所有你觉得可能有关的资料去解决问题或者为你提供解决思路。
3. 别惧怕英文
汉语博大精深，但是不得不承认，开发的世界里，英语还是母语，英语不好也没啥，现在各种字典的词库都是在线每天更新的，不会拼或者不认识就查一下就好了。
不惧怕英语的心态能帮你克服很多。在提问上，有些技术方向国内是小众搜不到解决方式的，那么可以尝试把问题翻译成英文再google的，我很多问题都是用英文搜索到的；此外，有些解答，你需要看懂，有些文档还没中文的，你需要看，那么就必须硬着头皮看下去的。心态不惧怕，再有字典帮助，没啥的。
二. 再思考和尝试
这一步我单独拎出来说，不管是搜索也好，社区提问也罢，永远不要认为一定可以找到直接解决问题的方式（代码）。
有时候，搜索引擎帮你找到一些类似的文章或者问题，你虽然不能立马解决你的问题，但是可以从中获得启示，然后加上你自己的思考，亲自做一些尝试，问题可能就被你K.O了。
一定要先搜索，再尝试，后思考，再搜索尝试思考，直到你觉得是时候提问了。
三. 组织你的提问
怎么组织好一个问题，这是提问中最关键的一步，也是很多人忽视的一步，很多问题没做好，导致被忽视或被踩。
1. 问什么——这个自己一定要清楚
在提问的时候，自己一定要清楚自己要问什么，是问思路？还是某个功能的代码片段？还是内在原理？是在什么环境中？...要表达清楚，不然答主们都不知道要给什么。
比如，有人问“我怎么获取第一个p标签啊”，有人回答$('p').first(),后来才知道她想在css中获取，应该是p:first-child，这就是没表达清楚。
2. 标题
“各位大神看看...”、“虽然我知道这个问题很基础，但是我还是解决不了，麻烦大家看一看”、“这个怎么balabala,有没有大神做过这个项目”...
一般遇到“求大神看看的”，我都是不看，因为我不是大神。你要知道，“大神”这个词真的是没什么卵用啊！真的！我保证！
然后，一长串“唐僧念经”一样的标题，要是在以前用电报发，用字来算钱的，看你还这么取标题！
正常的标题，应该是一句话描述自己遇到的问题，让那些坐在电脑前的开发者朋友们能一眼定位自己要不要打开这个问题（也就是能不能回答一下）。
当然有时候可能问题不能一句话描述清楚，那么标题，常规点可以是“有关在用XXX实现XXX过程中遇到的XXX问题”，然后在正文里面描述清楚。
记得，标题惜字如金，别说废话！
3. 问题的描述和最终要实现的目的
经常见到，有人提了一个问题，很奇怪，因为正常的开发过程中，我们不会这么做，而且有时候题主还会说“必须这样，不能XXXX”。
遇到这种问题，就不知道题主最终是要干嘛，所以可能大费周章地去帮题主解决问题，但很可能，只要题主把最终要实现的目的讲一下，答主们可能就可以换一个更合理的思路去解决，也绕开了答主的奇怪问题。
因此，在提出问题的时候，最好把最终是要实现一个什么功能讲清楚，交代好问题背景，是在实现什么功能的路上遇到了问题，然后再描述具体问题。
然后就到了问题的描述了，任何问题大致都是为了讲清楚，你要什么，但是你搞不定或者你得到了不一样的奇怪东西或者你的做法不合口味（报错？不一样的结果？效率不符合预期？太麻烦？...），然后你要么想知道why，要么想矫正过来达到你的预期。对的，就把现实（你的懵逼或者你的现有做法）和理想（你的预期）描述清楚就好了。
4. 尽量写上自己对此已有的思考和尝试
其实，这也是问题描述的一部分，但是这一点非常重要，在segmentfault感受不是特别深（实话），但是在stackoverflow感受特别深，如果你贸然问了一个问题，但是你丝毫不提及你为此已经做的努力，那么很可能在底下的回答中，你就会被“喷”，“你为什么不自己先尝试下呢”，“你该写上你目前做了啥，而不是一味求解答”，然后你的问题可能会被踩...(别问我为什么印象深刻，2333)
所以提出某一个问题的时候，请尽量带上你自己的一些做法，哪怕是错的（肯定是错的，不然你就不会有问题了啊），这样答主们也知道你是思考过这个问题的，也避免了答主们再去尝试你的做法，也可能你的解决其实是对的，但是有一些小问题，修正了就可以了，所以一定要这么做。
5. 有要用代码说明的一定要上“减肥后”的代码
大部分问题都需要上一部分代码的，没有代码就是空对空，鬼知道你经历了什麽！
但是上代码不是ctrl+A,然后ctrl+c，再用ctrl+v上啊喂！
和你的问题直接相关的可能就10多行代码，结果你一定要把你整一个文件的代码都搬上来，华丽丽上百行，看着就累，更别说代码排版还是混乱的，不对齐的，看着就没食欲。
要找到和你认为和你的问题相关的代码，然后有选择地搬上来；另外，可以为了这个问题，构造一个最佳最小化问题，即能说明你的问题的案例代码，使它不至于太臃肿。
四. 跟进你的提问
提问了之后无非是这么几种结局，没人回答的，有人回答但是不够直接的，回答能合理解决问题的，回答的都没解决问题的后来自己解决了的。
1. 没人回答
要么你不够耐心，要么你的提问大家没懂，要么你的问题比较小众。
你需要先反思下自己，自己有没有把问题描述清楚，有没有没有交待的细节，如果这方面没有问题，那么可能你的问题比较小众，可能尝试用英文去搜搜看一些国外的站点。
2. 没有直接用代码回应
可能答主只是提供一个思路，那么如果是自己没想到的，可能去试试看，而不是没见到代码就追问“那么这个代码该怎么写呢”，实在不会写，你也可以在问题描述里po一些自己的代码，别伸手就要码。
3. 及时回复问题下的回答
不管有没有解决你的问题，对于一些上心的回答，要及时回应，至于一些很水的回答就算了，自己把握，回答的方式能不能解决你的问题，不能是怎么个不能，这样可以让答主回过来审视自己的回答，每个人都有疏忽的时候。
如果有回答能很好地解决自己的问题，记得及时道谢（一个好习惯而已）和采纳。
4. 如果是没人有解决方式，后来自己解决了的
回来补上你的解决之道吧，因为可能相同的问题，世界的某一个角落有人和你一样正在啃指甲...
五. 小结
遇到问题，先搜一些资料，再思考和尝试，自力更生，丰衣足食，还是解决不了，那就真的是一个问题，好好组织你的提问，把问题背景、具体问题、你的尝试、你的代码交代清楚，最后别提个问题就消失，16年后再提个问题再消失...
