前后端分离之设想

关于「前后端分离」，这个概念已经出来好几年了，国内外有很多公司和产品采取了这种方式。这是一种在我看来较为先进的开发方式，它改变的不仅仅是一个 web 应用的系统架构，还有 web 工程师之间的协作方式，对「前端工程师」这个职业的发展产生了很大的影响。

我所理解的「前后端分离」，在之前写的文章中有提到——

「前端」和「后端」并不应该用设备、平台来划分，而应以关注点和职责来划分——与人机交互及数据展现相关的都算是「前端」，即 Controller 层和 View 层；与业务逻辑及数据存储相关的都算是「后端」，即 Model 层。

欧雷《团队中的 Node.js 实践》

如果这种划分方式真的成为主流，如今的「前端工程师」将会脱胎换骨，成为类似于客户端工程师的存在。至于为什么不是成为「客户端工程师」的一个细分职业，是因为网页毕竟不是直接运行在操作系统上，而是在其他的应用软件当中。

为什么要变

我们想做前后端分离的原因有很多，但这毕竟是前端团队发起的，要想在整个开发团队中推动并获得后端开发人员乃至上级的认同，必须得举着「大义」的旗帜。

作为一家电商行业的互联网公司，活动相关的需求总是源源不断的。虽然已经有个叫做「简易活动模板」的能够让运营童鞋自己动手创建活动页的系统，但设计师的思维是活跃的，不一定什么时候脑子突然「噼咔噼咔」一下就想出了一堆「好玩儿」的点子，设计出单凭那「简易」的模板系统已经无法满足的页面。这时，就得人肉切图了。

切图没关系，切就切呗！只要不考虑 SEO 问题，祭出我们前端的绝技「三刀切」大法，三下五除二就切好一个页面。然而，现在很多活动页是内嵌在 APP 中的，需要读取一些后端数据，这就要有后端开发人员进行配合了。两个人吭哧吭哧好不容易联调结束，走一遍 Git Flow 流程将代码合并进 master 分支后让后端开发人员通过发布系统部署到线上。

没过多久，也许是几分钟，没准是几小时，有可能是几天，运营童鞋悄悄地来到身边静静地蹲下，很有礼貌地开口了：「＊＊需要小小地调整一下，这个地方没多少改动，应该很快能改好（上线）吧？」可是，他们所得到的回复基本是：「这个得跟今天晚上的发布一起上线。」在听到这句话后，我能想象得出他们的表情——

运营童鞋肯定会在心里咆哮：「改这么点东西也要等那么久？！公司养你们这些人是干什么吃的？！」

每次接到新的需求后，在做页面时都会出现类似的问题——

后端模板要谁来写呢？如果是后端去套用前端写的静态页面，他们 HTML 肯定写得不规范，到时出现任何问题还得跑来问前端；但若是前端去写，不知道数据输出后具体是什么样子，到时还得后端去把文本部分替换成变量，也可能会导致样式崩溃，并且还需要他们去配置访问页面的 URL 与模板关联。

当前端对跟他配合的后端说：「＊＊，你帮我把 URL 加一下。」后端童鞋不明所以，一脸懵逼：「啊？」前端有点无奈：「访问页面的 URL 啊，你不配置一下我怎么调试？」后端的反射弧突然变得有点狭长，停顿了几秒钟才从他嘴里冒出：「哦……」

我想，大部分 web 开发人员都会遇到这些问题。仅仅是做个页面而已，却要跟后端开发来来回回交涉好多次。这种沟通完全没必要，真是浪费口水，浪费时间，浪费心情！

我们的「卖好车」分前台系统和后台系统，其中前台是给商家用户使用的，后台是给公司内部使用的。它们是两个 Java 应用，因为都涉及到商家用户的数据，所以在进行数据操作时必然会有很多相同或相似的业务逻辑，这样就要在每个应用中各写一遍。

基本每个工程师都将「DRY 原则」融入血液，遇到这种情况就会不自觉地想要去把可复用部分抽象出来。我们的后端工程师也是如此去做了，将两个应用的通用部分提取出来形成第三个应用，那两个应用通过 RPC 在第三个应用上进行数据的读写。

不过，我觉得这只是临时方案，并没有解决根本问题——灵活性差。将应用服务化才是王道！不必考虑展示层如何实现，只提供可用的服务。想要做 web 端就拉个前端工程师来写页面，路由、样式、交互全包；想要搞客户端就找 iOS 工程师或（和）安卓工程师开发。一个服务可以被多个服务调用，不同服务之间可以相互调用；一个功能想用就接上，不想用就拿掉，想怎么拼就怎么拼！

由于「买好车」已经没有新需求，也几乎不需要维护；「卖好车」的侧重点是 APP，唯一一个重度使用的 web 端是后台系统，可它的页面基本都是后端工程师自己写的。如此一来，我们前端团队自然而然地趋向边缘化。

每周写周报时不知道写什么是小事，但团队以及成员个人的发展不能置之不理！我们必须得做出点什么来提升影响力，借助于前端技术的力量去改善开发团队的开发效率和提高产品的用户体验！

要变成啥样

我所期望的理想状态是前、后端各司其职，专业的人做专业的事；系统架构弹性十足，比「今麦郎」弹面还要弹千倍万倍！

编写前端代码完全脱离于后端框架，不必局限于它的目录结构，不用考虑到它的运行机制。使前端工程师能够更随心所欲、更无所顾忌地编写代码，专注于前端的交互逻辑和工程问题。

如若做到这点，页面的渲染方式就可以让前端工程师根据业务场景来选择，是「单页面应用」式的浏览器渲染，还是像淘宝的「中途岛」那样通过 Node.js 作为中间层在服务器渲染。

前端工程师不必学后端语言，后端工程师不用懂前端技术。各自的开发工作不会被对方的工具链、运行环境所影响，开发进度不会被对方的能力水平等因素所拖累。

前、后端工程师之间的沟通大量缩减，变为以 API 文档为中心进行交流。在设计 API 时按照规范讨论决定，尽可能考虑各种情况以减少文档变更以及因此产生的沟通成本。

待解决问题

数据接口开发

生成假数据

无缝切流量

• Nginx 配置文件引入

旧页面迁移

接口环境切换

• 设置 cookie

部署发布策略

日志监控报警