前言
俗话说的好，万事开头难。据说，在编程这条路上，大多数放弃者没能熬过6个月。
我想无论是新老同学，在学习之初一定都遇到过这样的困惑：
- "我遇到了一个很具体的问题，但我不知道应该怎么准确描述和提问。"
- "要是身边有个大神来看看我的代码，指导我一下就好了。"
- "我的程序不符合我的预期，我该怎么在网上找解决办法？"
作为一个自学转行的前端老鸟，我也曾经加过一些初学者群，热心的我期望可以帮助他们，但是很快我就发现群内充斥着这样的提问：
当你看到这些问题的时候，是不是也血压飙升，满脑子的困惑：
『这问的都是什么玩意儿』？
经过我仔细观察，发现所有『低效的提问』，基本都具备以下特点：
- 无法准确描述上下文。
- 无效信息过多。
- 无法提供可复现样例。
- 没有贴出有效的异常日志，及异常栈。
- 纯知识性问题，没有尝试利用搜索引擎。
那么，我们应该怎么提出『高效的问题』呢？
一、加法：保留问题的上下文
什么是问题的上下文 ？
简单地说，就是你的问题出现的环境。
- 我使用的是什么框架？什么版本？
- 我试图达到什么效果，用了什么API，传了什么参数。
- 我用的什么浏览器？哪个版本？ ...
诸如此类。
理论上，如果你能够完全提供问题的『上下文』，就等于说你把你的所有源码传递给了目标，对方能完全执行和你一致的代码。
但很可惜，这不现实。你的本地环境，你的职业操守，都不可能让对方完全复刻你正在遭遇的环境。
但无论何时何地，尽可能多的传递信息，总是更好的选择。
尝试体会下面两个同学的提问：
你觉得 A 与 B 这两位同学，谁会更容易获取到社区的帮助，寻求到他想知道的答案呢？
答案是不言而喻的，有经验的开发者看到 B 同学的提问，可以快速猜测出几个常见的问题，从而和 B 同学完成有效沟通，找出真正的问题所在。
反观 A 同学的提问，没有充足的上下文信息，哪怕是经验最丰富的老开发，也无法根据这一行字反推问题原因。（好耶，又可以以寻求帮助为名在群里摸鱼了）
有的同学现在一拍大腿：『我懂了！问问题的时候要多问，多铺陈信息！』
对，但不完全对。
往下看。
二、减法：尝试简化你的问题
又有人说：在提问的世界，少就是多。
这里的『少』，是说提问时，牵扯的无关内容要尽可能『少』。
看看下面这个哥们的提问，你觉得如何？
其实真正的问题只有一句话：『怎么才能做到点击链接在新窗口打开？』
除这句话以外的很多信息，其实都是无用信息。
无用信息不仅无法对『解答问题』产生任何帮助，在某些情况下甚至可能会扰乱答疑者的思路。
那么问题来了？
『保留上下文』和『简化问题』难道不是冲突的吗？
如果不冲突，如何区分 『上下文』 和 『无用信息』？
我的思路是：划清界限。原则如下：
- 前后端的界限画清，如果是纯前端问题（不涉及接口和数据交互），则尽量不要提到服务端相关技术。（如：例子中的所有服务端技术）
- 如果不涉及到具体的业务，相关功能性框架可以不用描述。（如：例子中的
vuex、shiro、log4j2） - 除非是样式问题，否则无需描述布局和样式。（如：例子中的
display: inline-block等）
按此原则梳理一遍，留下来的通常是可能对问题有用的信息。如例子中的问题，梳理过后如下：
我使用
vue2.0+ElementUI，应该如何在点击链接时，在新页面打开链接。
虽然实际在这个例子中，vue2.0 + ElementUI 对解答问题本身没有起到帮助。但新人在无法断定『它们是否是问题上下文』的情况下，带上这类必要信息，也并不会产生太大的干扰。
三、 神器：可复现样例
可复现样例，永远的神！
描述可能不清楚，表达可能不准确，但是我辈老鸟程序员最擅长的事情是什么？
看我口型：（摸鱼） 改BUG!
你跟一个程序员描述10遍问题，也不如直接把BUG怼到他们脸上来得管用。
一旦BUG骑脸，那就不再是大佬是否愿意指导你的问题了，而是大佬和BUG不死不休的局面了。
那么，怎样提供最小可复现用例呢？
3.1 低阶：打包zip扔过来
虽然这行为非常的不入流，但只要你的项目不涉及『商业机密』和『安全问题』，那这确实是直接而简单的办法，扔出去一个zip，也许能收获一个答案呢。
3.2 中阶：一个github仓库扔过来
当你开始熟悉一些开源社区的玩法，并且你也深感『直接把手头的项目』扔给解答者是一件不合理的事情后，你会开始尝试简化自己的『可复现样例』。
在删除一些和你当前问题无关的点后，它们可以成为一个demo ，一个 git 仓库，而且也不再带有你的环境信息、个人信息等其他信息，这显然比扔 zip 包更高级也更安全。
3.3 高阶：一个链接扔过来
当前生态对前端可太友善了，N多的『在线样例』构建平台可供我们选择。当我们希望快速搭建一个 demo 时，我们甚至无需去搭建一个项目，就能快速写出可复现的代码。
最主流的几款如下：
| 产品 | 链接 |
|---|---|
| jsfiddle | jsfiddle.net/ |
| codepen | codepen.io/ |
| codesandbox | codesandbox.io/ |
| jsrun(国内的) | jsrun.net/ |
在这些产品上，你可以快速搭建一个『符合你场景』的 demo，并且在你描述出问题后，可以通过一个简单的『链接』让答疑者快速访问你构建的页面。
让答疑者『解决』问题和了解问题的门槛进一步降低。
例如，访问这个链接：codesandbox.io/s/gracious-… 你将能够快速访问一个 element-plus 的 demo，并可以在上面轻松印证自己的代码。
能动手的就不动嘴，Just show me your code !
四、组合拳：异常日志和异常代码
错误的原因，浏览器已经告诉你了。
经常看到有刚刚接触编程的新人，在技术交流群内发一段代码，然后询问：
"各位大佬，帮忙看一眼代码，请问哪里不对？"
与其让群内大佬 人脑编译 更靠谱的方式显然是同时贴出『异常日志』。
不过，陈列『异常日志』也是有技巧的。按我的经验，是『异常文本』小于 『异常截图』，『异常截图』小于『异常截图 + 异常代码』。
这样一来，定位异常代码的具体位置、具体原因将变得更加容易且有凭有据。
毕竟，程序员不是算命的，没办法靠『掐指一算』。
五、MDN、某度、某歌、某stackoverflow、github issues
凡是能在某度第一页找到的答案，就不值得去询问他人。
- “请问下，vue.use方法有啥用？”
- “各位大佬，Array.reduce是干啥的？”
- “渐变背景色应该怎么写？”
.......
在前端新人群内，总是非常容易看到以上问题，按我本人的理解，当某人提出以上问题时，那么他可能并不是真的想询问问题的解决之道，而是单纯的想和“群友”聊聊天，摸摸鱼，给老板上一课。
否则我完全找不到理由他为什么要在QQ或微信的聊天框内输入上面的文本，而不是在某度某歌的输入框内进行输入。
而 『某度 => MDN => 某歌 => 某stackoverflow => github issues』正是我碰到各类问题时最常用的搜索顺序，有浅到深，总能找到相关的答案或指引。
六、总结
当你遇到问题，想到提问时，请您先思考以下问题：
- 它是否是知识性问题，能否在某度某歌的第一页找到答案？
- 你关于问题的描述里，上下文是否足够？
- 是否有剔除问题中的无关信息？
- 你是否能为这个问题构建一个“最小可复现案例”？
- 你是否有附上丰富而详细的异常日志和定位代码？
