一、职责划分

前端

前端工作专注业务的页面呈现，非常注重用户体验度，也是与各种角色打交道最多的。

比如：

1. 前端开发人员会经常与产品经理或者客户讨论页面样式、视觉效果，页面布局等各种页面渲染效果

2. 前端开发人员要与UI设计师对接：字体大小、颜色、页面布局、样式等

3. 前端开发人员与多个后端开发人员接口对接

4. 前端开发人员与测试人员基于bug修复讨论

一般前端工作包括六个部分：

1、UI设计师与产品经理对接需求

2、UI设计：UI设计师设计高保真图，给前端开发人员设计真实页面

3、页面开发：根据UI设计师提供的高保真图，进行页面模块开发

4、前后端接口对接：与后端开发人员对接API接口

5、前后端联调测试：包括页面展示以及接口数据

6、bug修复

后端

如果前后端职责划分很清楚的话，后端更多开发工作在于业务接口设计、业务逻辑处理以及数据的持久化存储，并提供详细的接口设计文档给前端开发人员使用。

一般后端工作包括五个部分：

1、与产品经理对接需求

2、业务API接口开发：根据根据需求文档进行业务接口开发

4、接口对接：与前端开发人员接口对接

5、前后端联调测试：包括页面展示以及接口数据

6、bug修复

二、技术划分

前端开发技术栈

h5、css、nodejs/vue/angular/react、webpack、hbuilder/vscode等

后端开发技术栈

后端更注重业务逻辑处理，以数据为中心，关注数据存储及高并发请求等。

SpringCloud/Springboot、SpringMVC、ORM框架、数据库、缓存框架（Redis，Codis\Memcached等），大数据框架（Hadoop/Spark/hive/Hbase/Storm/ES/Kafka等）等等

三、我们约定

技术选型

最好选择成熟稳定，易上手、开发效率高的技术，因为实际项目开发时间是有限的，开发人员没有多少精力放在学习和深度研究技术上。

数据格式

后端开发提供接口设计文档，详细写明每个接口的请求地址、请求参数、响应参数等等；一般采用REST风格以JSON格式提供数据。

接口设计

一个接口设计的好坏，直接影响到前后端一些沟通协调问题。

依笔者经验来看，如果后端接口不稳定，会导致前端开发人员反复修改页面数据呈现。常常出现后端开发说这是前端问题，前端开发说是后端问题，来回扯皮，沟通效率低下。

从前端开发的角度来说，他们更关注用户体验效果， 因为客户看到的是最终页面，页面效果以及数据呈现效果的好坏最能反映客户的满意度的。客户不关注你用了什么牛逼的技术，有什么牛逼的人。

从后端开发角度来说，他们更关注程序的可靠性、稳定性、安全性以及是数据完整性、一致性等。

所以前后端双方关注点不同，难免会涉及到一些工作量大小问题。例如接口粒度问题

接口容量问题

一个接口的业务容量大小，往往代表前后端工作量的大小。

如果一个接口的业务容量太小，前端需要分阶段处理的事情就多，尤其是对多个接口Ajax异步处理；如果一个接口的业务容量太大，那么业务耦合性高，万一需求变更，后端程序改动大，不利于程序的扩展。

四、分离带来的优势

1. 前后端职责分明，分工明细

2. 局部变化，不会影响所有业务功能；也不会因为某局部功能修改，而导致所有程序重启服务。

3. 开发效率高，在不涉及接口联调时，前后端互不干扰

4. 联调简单，前后端保证API接口规范稳定就行

5. 问题责任清晰，联调/测试/预发/上线/bug，都能马上定位是哪方的问题。

6. 自动化部署：容器化部署：docker+k8s

五、分离带来的问题

一、前后端分离思想要转变

不能老是按照传统WEB（js/h5/css/后端代码放在一个工程）开发思维去看待前后端分离

二、沟通成本问题

以前传统WEB开发，开发人员从需求到设计到开发基本上是一个人。而前后端分离后，前端只负责页面呈现，后端更注重业务逻辑处理以及数据的持久化，双发都有自己的侧重点，工作量上有私心。

三、组织结构问题

康威定律

第一定律：Communication dictates design（组织沟通方式会通过系统设计表达出来）

第二定律：There is never enough time to do something right, but there is always enough time to do it over（时间再多一件事情也不可能做的完美，但总有时间做完一件事情）

第三定律：There is a homomorphism from the linear graph of a system to the linear graph of its design organization（线型系统和线型组织架构间有潜在的异质同态特性）

第四定律： The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems（大的系统组织总是比小系统更倾向于分解）

康威定律说明以下几点

1. 人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理

2. 组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计

3. 如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更合理高效

4. 复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的

四、部署及监控运维

前后端分离后，拆分的服务会带来线上部署以及如何监控运维的复杂性。

六、总结

总体来说，前后分离所带来的好处还是更明显的。一个成熟的前后端分离的团队，文档化约定，前后端职责分离、接口约定都是做的比较好的