打卡君最近很头疼，公司在推前后端分离，但一群后端大佬迟迟下不了决心。总是问打卡君前后端分离的好处是什么？为什么要做前后端分离？在打卡君心里，对于现在的互联网发展来说这种主流的做法是理所当然。如果你是一个在某领域深耕的大牛，虽经历了从当年的撸码到如今各种开发设计模式井喷，但选择性的忽略了前端的发展，或者是职场新猿，或者身在传统公司，未有了解前端的变化，就有必要好好的了解下打卡君的这篇文章。声明一下，打卡君能力有限，若有谬误处，请海涵。
技术的发展总是那么快，打卡君刚毕业接触的技术还是asp之类，再到aspx,jsp，再到前几年大火的MVC,然后是api,一核多端，再到如今追求的技术，一套代码，适用任何环境。如果我们继续停留，如何保证我们跟上技术的步伐，以快速满足用户需求？以及提升自身的实力？
战国时，名家总是辩一些白马非马，大王非王的问题。打卡君不想做一些这样看似无理的辩驳，打卡君会从自身工作中遇到的痛点来分析这个事情。那我们就从本质上说起，慢慢道来。
前端是什么？做什么事？
我们首先要透过现象看本质，不要到头来争论来争论去，连要争论的焦点都没搞清楚。在web的领域里看：
前端是页面，前端是数据的载体前端离用户很近，对用户操作做出反应前端决定用户体验，需要流畅完美总之，前端就是从用户操作到最终结果展示给用户，整个过程要完美流畅友好的形成一个闭环。这里面说的没有前端分离不分离的事，不分离的展现给用户的那一层也是前端，只不过它离后端也很近，对于浏览器解析器来说，都是一样的，只是对工程层面的实现和开必人员来说，它是有区别的，当然技术人员是从技术的角度来看待它。
技术？或者工程？
前端是一种技术吗？我们选择哪种前端实现方式是否跟技术有关？打卡君觉得，前端只是一种一个工程中的一个类别，一个名称，用于区分像后端接口，数据库。广义上讲前端包含的是各个终端，安卓app，IOSapp，及各个硬件展示屏，都可以广义上称为前端。
我们这里说的前端特指web前端，下同。实现前端的技术有很多，在一个项目中，怎么选择自己的实现技术，除去数据库设计，后端模式设计，前端作为工程中重要的一环，有必要重视起来。俗话说行百里者半九十，互联网界现在总是提一个名词，叫打通最后一公里。那么打卡君想说，从纯技术角度来说，前端就是最后的一公里，就是要跟用户接触的一环。如果这么重要的一环不能很好的做出选择，那你的数据库，分布式设计的再好，后端用了再多美妙的设计模式，美妙的算法。如何让用户感知，是一个很重要的问题。举个例子，对于用户来说，哪怕一个按钮点起来很生硬，没有按下去的感觉？一切都变得糟糕了，你的分布式，美妙算法可能用户不感冒。现在硬件水平发展越来越高，各种服务越来越方便，用户都养成了这种适应便捷的习惯，你突然给它一个很生硬的前端，那是什么画面？那有人说？不分离就不能把按钮做的点起来很舒服吗？这是我们下面所要说的
专业人，专业事
韩愈说：闻道有先后，术业有专攻，如是而已。
前后端分离很好的解决了专业的人做专业的事的问题。当年做程序员的都知道，那时的前后端混沌不开，做项目做模块是从数据库到前端一个人全搞定的，可能对于职场新猿来说，哇，这看起来太棒了。全栈啊，崇拜之情溢于言表。但我们心里知道，此全栈非彼全栈也。那个时候出来的程序员，如果没有睁眼看世界的话，再以原来的眼光来看现在的前端，难免产生误解。云：前端不就是jshtmlcss吗？当年老子，每天手写页面三四张，千百行js代码手到擒来。有什么难的，不就是页面吗？你们前端随便调调样式就搞定了，重点在于我们后端。
听到这，打卡君是委屈的，因为打卡君以前也是后端，也是这样的眼光，居心甚傲。想要转变自己对某事的看法，就要透过现象看本质，真正了解这个东西。随着做技术的慢慢深入，打卡君慢慢转变了，明白了原来前端还可以这个样子。
那是零九年五月，平地惊雷，NodeJs横空出世。可能当时很多人还在睡梦中，过去了这么多年，还是有一大批从业者同样在睡梦中。nodeJs的出现，对前端来说是革命，从此潘多拉盒子被打开，各种包，各种前端架构风起云涌，服务器渲染，node解析器使js不再局限于跑在浏览器上，同样可以跑在服务器的node解析器上，脱离浏览器，那这样就赋予了Js更强大的生命力，有了可以做后端的能力，所谓大前端，大有取代后端之势。一时风光无两。从出现到现在，nodeJs的这种前端开发模式渐渐变成了现在的主流开发模式。
从技术上说，node的出现使前端的代码和框架设计与后端越来越像，看下一个react项目的前端架构，以图为证：
看看，service层后端有没有？utility里各种helper类有没有，redux相当于facede有没有？view相当于controller没有没？
架构看完，我们再简单看下代码：
importUtilityfromUTIL/utility;classExampleextendsComponent{constructor(props){super(props)this.state={}}staticcontextTypes={callback:PropTypes.func}render(){return()}}
java里导入包import，前端也有。class在Javascript实现，等等。好的东西都殊途同归，虽然最初一个向左，一个向右，但是，你别忘记，地球是圆的。
如果这种前端模式摆在一个思想里还是前端就是html页面里写点JS的人面前，那么我想他是懵的。洞中刚数月，世上已千年。所以保证前端人员的专业化很重要，发展趋势摆在这里。在技术上来讲，对于一个需要技术保证活力的公司，这是必须的。因为专业，所以优秀。
调试及联调
拿打卡君的亲身经历来说吧，我们的大多数项目前后端都是不分离的，后端用的Java那一套框架，我虽然不写Java，但maven+springboot+mybatis+redis这套我耳朵都快听出酱紫了。前端用的是vm(相当于JSP,一个Java的模板引擎)。
现实就是这样的，在实际项目开发中，我们前端很痛苦，后端同学也跟我说，他们也很痛苦。说到这，打卡君在想，官逼民反，民不得不反。为何偶们没革命，起黄巾。当然，这是开玩笑的，既然双方都感觉到痛苦，为什么到现在没分（前后端分离）？是我们感情很深吗？舍不得？也许吧。
我们前端现在的日常是：
“喂，打卡君，来帮我调下这段js，这怎么过不去啊？”“好的，起来，我坐你电脑前调试”...哎呀，怎么启动啊，这么慢？...
回头看到后端同学一脸茫然的站在我身后，打量着玩手机。十分钟过后，可以了。
二十分钟后：
“喂，打卡君，来看看这个样式，这阴影怎么调？”“好的，起来，我坐你电脑前调试”...哎呀，怎么启动啊，这么慢？...
回头依旧后端同学一脸茫然的站在我身后，依旧打量着手机。
在这里打卡君想问一句，是我们的代码能力弱吗？时间都去哪了？
如果遇到前端问题，你恰巧遇到一个黑脸的后端，那么情景是这样的：
“哎呀，不要在我电脑上调了。我还有很多事要忙哟，你在你电脑上部个环境，跑起来”
听到这，打卡君，一脸茫然的站在风中凌乱，内心是绝望的。没有办法，自己弄环境吧，在部的过程中，“这pom配置少了，这tomcat不好用，maven加载包怎么这么慢？像我们前端，轻量级，什么这环境那环境，我node一启，五秒钟，准跑起来。”边操作，打卡君边发着牢骚。最后，费了九牛二虎之力，对不起，还是没搞定。
“G大神，来帮我看看吧。”“好的，起来，我坐你电脑前看”“哎呀，pom都配了啊，怎么还启动失败？哎呀，你tomcat是8啊,装个6”...哎呀，下载太慢，我电脑上的tomcat6直接发你吧
五分钟后
“这下应该可以了”，G大神信心满满“启，擦，这是什么鬼，我擦，小M，这是什么配置，你加的吗？”
G大神冲着对面的另一个后端喊
“我看看啊，是啊，是我加的”M弱弱的说。
....少则半小时，多则一小时。
此时打卡君，一脸茫然的站在风中凌乱,内心依旧是绝望的。
在这里打卡君想问一句，我要写代码啊？但时间都去哪了？
说了开发问题，再说说线上的问题。有一次，产品提需求说，这