前后端工程师之争，恰似文武权臣之争一样，你说你厉害，他说他很强。其实少了谁都不行，前端负责界面的设计，后端负责数据的管理，二者只有很好地对接起来才能使一个项目变得完整。下面简要说一下前后端分离的历史。 

回顾Web发展的30年来，技术栈大概经历了静态页面，js 带来动态效果，动态脚本语言阶段，mvc 阶段，前后端分离阶段这么几个阶段。

 从宏观上来说，前端技术栈的独立是首先是各种前端框架和前端的工程实践配套基础设施后的的必然产物，目的是提高前端工程的开发效率和管理能力；从个体的角度来说，前端技术框架的出现可以在复杂前端开发的场景中减少开发负担，代码写起来更漂亮，更舒服。所以，无论从宏观角度还是个人开发者的角度来说，前端技术栈的出现动机，并不是为了划分责任田，它只是个工具，只是个为了处理view层开发中的各种痛点出现的工具。

 尽管没有划分责任田的动机，但是前端技术栈的出现还驱动出了责任田的划分，典型的标志就是前端工程师，后端工程师这种角色的划分开始的。在前后端工程师的划分出现之前，一个Web开发人员默认是必须会前端的，即使不是特别精通，起码要具备独立开发前端的能力。也就是说，起码在MVC时代，一个Web开发人员，起码应该是有独立的交付能力的。这里对独立交付能力的定义是： 无论代码质量如何，起码能能力开发出一个具有使用价值的产物。

 客观来说，确实前端工程实践和后端工程近些年来都在向纵深发展。前端领域Vue，React，Angular 等等的框架让众多重心在前端的人员有了幸福的烦恼： 真学不动了；后端领域，以Java为例，Spring 生态依旧繁荣，各种迭代还在一路向前，一眼不愁，已经过去了好几个版本号，微服务的风口下，似乎一个Java开发不懂微服务都不好意思和人打招呼，各种数据库还算你方唱罢我登场，mysql 来到了8.X， mongodb 也越来越多的工程实践中看到，redis 也开始了多线程的模型来实现.......作为一个开发人员来说，如果一个人全部都要学，精力真的有限，选择前端或者后端领域来发展，也是非常合理的。加上现在前后端分离开发也是市场上的主流，选择前端或者后端，只要是个人选择，都无可厚非。

 在理想的前后端分离实践中，前后端是可以并行开发的，前端没必要等到后端开发完成才能进行开发，可以根据约定好的数据协议直接进行开发，双方都完成之后，这个软件就可以直接的run起来了。同时前后端都可以在自己的领域中去深耕，纵深学习和发展，提高个人能力。所以，前后端分离，无论是对个人，还是对公司，简直就是完美！

 不经意间已经陷入了对前后端分离之后的甜蜜想象.......但是睁开眼睛，看看现实，似乎真的是这样么？

 君可见前后端为了接口不同意争得面红耳赤？ 君可见前后端联调车祸现场一般的尴尬？ 君又曾可见测试，上线的日期一再dealy ？甚至好不容易熬到上线了，又突然来个紧急bug 的惨状？ 翻车之后呢？ 前后端都说不是自己的原因，自己没有过错，但是挂了就是挂了，这是唯一可以确认的事儿。 各种惨烈的前后端对接翻车现场分分钟直接把你对前后端分离的好梦中叫醒。

 但是这并不意外，因为前后端分离的各种好处本来就是建立在理论上的理想情况，不建立在实际场景下的假设都始终是假设，禁不住现实的检验。现实情况是，前后端分离人为的划分了责任田，大家都各扫门前雪，和自己没关系的，一概不关心，结果就是你不关心我，我也不关心你，我只认你的接口文档。本来是动态的开发过程，却依靠一个静态的开发文档，这个开发方式的前提就有问题。没有功能分解，没有及时验证反馈，等到双方都开发完毕了，才开始联调，才发现破镜无法重圆。

事情的经过就是这样的，我个人也很赏识单纯的前端工程师，因为那些优美的界面是我目前还不能轻松实现的。今天突然遇到的一个问题更加坚定了我的想法。

1、ERR引发的思考
创建好的 vue 项目直接执行 vue run dev 报错？运行 vue run serve 就可以启动...如下

npm run dev npm ERR! missing script: dev npm ERR! A complete log of this run can be found in: npm ERR! E:\nodejs\node_cache\_logs\2018-12-12T15_06_08_674Z-debug.log2、dev build serve?

其实 npm run dev 或者是 npm run serve 等 npm run xxx 并不是一定要这么写。
npm run XXX是执行配置在 package.json 中的脚本，比如：

"scripts": { "serve": "vue-cli-service serve", "build": "vue-cli-service build", "lint": "vue-cli-service lint" },

 npm run xxx 中的 xxx 可以理解为键值对的 key，实际上 run 的是在 package.json 里面 scripts 配置的 value；

 比如，npm run serve 实际运行的是 vue-cli-service serve；

 而放在 3.0 以前运行的则是 node build/dev-server.js 文件；

 这时候我们再来看上边的问题是不是豁然了呢， scripts 中并没有配置 dev ，所以控制台报了 [ missing script: dev ] 的错误 ；

npm run xxx，并不是你想运行就运行的，只有在 package.json scripts 配置了，你才能 run 的，所以不是所有的项目都能 npm run dev/build。

要了解这些命令做了什么，就要去scripts中看具体执行的是什么代码。

这里就像是一些命令的快捷方式，免去每次都要输入很长的的命令（比如 serve 那行）

一般项目都会有 build, dev, unit 等，所以起名，最起码要从名字上基本能看出来是干什么的。

用一句诗概括一下“术业有专攻 闻道有先后”！