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