前后端分离
事业部去年年底开始推前后端分离，到现在我参与了前端，也参与了后端。一点心得体会说一说。
首先为什么要前后端分离，其实原因没那么复杂，比较简单就一条。
- 试错，因为在这之前都是传统的研发，前后端不分家，至于是好还是不好，就不多说了，这个跟很多因素有关，比如客户场景、公司资源等等。既然有问题，所以就想试试新的玩法，看是否利大于弊。是否适合我们的公司和场景。
当然肯定不是随随便便的试错，试错是带有愿景的。
- 分流，清晰的职能划分，让大家更加专注，也给大家更多选择，当然还是尽量让专业的人做专业的事。
- 能跟上小步快跑的产品节奏，及时响应需求。
- 提升开发效率，并以此做好工程实践以及开发规范的落地。
目前来看愿景是基本上都达到了，只是有待精进。我要说的是，前后端分离后跟我们带来的最大的问题，即前后端的边界问题，哪些是前端干的哪些是后端干的。扯皮就从这儿拉开了帷幕。
前后端分离后很多友爱温馨的画面就出现了。
前端：这个字段能不能跟我处理一下.
后端：这个应该是前端干的，我不管。
前端：我顶你个肺，明明是后端处理更方便。
后端：我也顶你个肺，这个前端也能处理。
..........................
前端：这个数据能不能跟我转换一下.
后端：这个应该是前端干的，我不管。
前端：我顶你个肺，明明应该是后端处理。
后端：我也顶你个肺，这个明明是前端处理。
.................
后端：这个我这边不好处理，你多发一次请求自己组装吧。
前端：不应该是组装好了给我吗？
..........................
为什么会出现这样的局面，我认为究其原因就是前后端的边界不清晰，如果一开始没有一个前后端的《开发边界协议》，到后面就是各种甩锅的操作。前端抱怨后端，后端抱怨前端。慢慢的负能量。
我觉得边界的界定不是一刀切，应该是和公司文化、组织结构、业务场景等等契合的。在我们事业部，我认为可以从这些层面来作为划分边界的参考。
业务场景：因为我们是做的APM，本身就是监控别人，这样的系统在客户那儿大概率就是个二线系统，那你就不能奢望客户能给你怎样怎样的资源，我们自己心里有数，要做到尽可能的少用客户的资源，并且要响应快速。
人员配置：高层领导基于各方面的考虑，没有专门招聘更多专业的前端，而是从后端研发里抽调几人到前端，边学边做。
前后端实现的复杂度。
我们是这么做的，首先大的前提有两个：
- 所有的API跟着详设走，所有的前后端交互接口录入RAP，参数结构、返回数据结构、业务响应码、异常信息都做好了同步。
- 原则上前端只负责解析数据，后端负责组装数据。前端倾向于呈现。* 前端着重处理用户体验相关的问题；后端则倾处于业务逻辑、数据处理和持久化等。在设计清晰的情况下，后端只需要以数据为中心对业务处理算法负责，并按约定为前端提供 API 接口；而前端使用这些接口对用户体验负责-https://my.oschina.net/jamesfancy/blog/1604237*
但是有了这些前提之后前后端还是存在公共地带，有些是前端可以做后端也可以做。比如字段值得转换，某些数据的补点或者聚合等等，我们都会具体情况参照上面《开发边界协议》进行权衡。
1.比如需要前端多发请求的肯定移到后端，通过后端的tcp代替前端的http。
2.前端如果需要改多个地方，而后端只需要加一段代码的能实现的，由后端做。
3.业务逻辑尽量放在后端，前端聚焦于交互和样式。
4.前端不做复杂的运算，尽可能让前端小而轻，哪怕后端重一点也无所谓，因为后端有太多方案变快，但是前端页面、样式等就是一套，轻就是轻，重就是重。
5.参照伯斯塔尔法则，后端尽量严谨保守给数据，减少前端解析数据的多样性，前端做好数据解析的校验，尽量开放接收数据，不理想化。
其实说那么多，最重要的还是那句话，让专业的人做专业的事，让前端把大部分的精力都投入到交互、样式、以及优化上面。后端做好一切的兜底方案，前端要什么后端给什么就完了。
实际操作还是建议以前端为主导，因为前端是对用户负责。前端就像一个消息中心，研发阶段，対前连接产品、UCd、测试，对后对接后端服务提供方。所以前端主导后端兜底是比较合适的方案。
关键字解释
伯斯塔尔法则
源引：
/a.jpg "来自twitter")
