1.正常的开发流程
graph LR
分析需求 --> 分析原型
分析原型--> A[后端]
分析原型--> B[前端]
A--> 设计数据库 --> 接口设计-->开发
B--> 还原原型 --> 对接接口--> 开发
一般情况下是这么一个流程
2.现状分析
2.1 交集部分
前端与后端的交集部分就在于接口IO的数据，前端传给后端的数据，和后端返回给前端的数据。
2.2 正常情况
正常情况下，后端根据数据库定义POJO，然后开发Controller，前端也是根据后端定义的VO（展示）或者DTO（数据传输）的数据结构来进行数据的扁平化。
2.3 现实
回归现实，大部分小公司或者小团队，因为时间成本和各种原因并不会先设计接口，这会导致以下问题
-
前端空档期，前端绘制完"死"页面，在ui库的帮助下会快速很多
-
前端返工期，如果在没有数据格式的情况下，前端在定义表单或者表格这些需要绑定的字段的时候，必然会自己定义,就会设计多处返工。
- ts定义的字段修改
- 如果有国际化国际化需要修改
- 表单表格绑定字段的修改
- 需要一一对比去对应字段
- 如果说有些联动或者hooks使用到字段需要注意
-
前端的周期会大幅度增加，心智负担过重，可能开发完两三个业务模块才有第一块后端业务模块开发完，在开发过程中来回切换业务模块思路，还需要不断记住之前的代码处理需要干什么。
-
前端算是一层"弱测试"，在对接完接口后还需要调用一下，如果有报错或者调不通，后端进行修改，期间又要搁浅这块模块的思路，切换成另外的业务模块开发。
3.个人想到的解决思路
3.1 搞事情
如果是个搞事情的人，那就直接向上反应。
优点：
- 规范了开发规范
缺点：
- 首先你得是个举足轻重的人，一般业务开发都是前端1v2|3|4,你得有把握破坏平衡
- 只能说减少了大部分返工期，因为在开发过程中不可避免的会修改字段或者增加字段，你还是要一个一个的对，不可能奢望及时通知
3.2 跳槽
换个好点的公司，有的公司修改接口设置，修改表字段，字段名都是有规范的，要求留痕，后期问责
优点：
- 开发舒服了
缺点：
- 公司不好找
- 锅不好甩
- 这种公司review也很严格，自己也会被限制很多自由
3.3 全干工程师
自己把前后端都开发了，一条龙服务。
优点：
- 及时通信，自己改的东西自己知道，立马通知到位
- 数据处理哪边方便写哪边
- 自由度更高
缺点：
- 工资没加干两份活
- 锅没跑了
3.4 借用后端思想-平衡减少部分前端无用工作量
前面都是开玩笑，这是我目前自己的一个开发现状。
借用了后端各种O的思想，DO DTO VO PO啥的七七八八
3.4.1 VO
VO 是一种不变的对象，通常用于表示某个数据的抽象，在系统中用于传递只读数据，常用于展示层。
通过这个定义，不可变说的不就是“死页面”吗？如我们前端的表头，表单要绑定的name或者key之类的。
3.4.2 DTO
DTO 用于在不同层之间传输数据，通常用于服务层与控制层之间的数据传输。DTO 可以是可变的，通常包含 getter 和 setter 方法。
这个定义，像不像在说我们前端给后端传数据。
3.4.3 更改后的流程
那么我们开发的流程就可以
graph LR
开发页面 --> 定义TS
定义TS --> interface-xxxVO --> 前端绑定VO定义 --> 建立前后端字段映射 --> 定义转换函数
我们就可以前端不用管后端的情况下进行开发，最后只要在获取展示接口和提交数据的时候编写好转换函数进行处理就好了
3.4.4 优缺点
首先我们需要摆正一个想法，前端的数据和后端的数据本来就不是一个东西，不要因为个别的差异在那各种类型体操，用类型体操是可以，但是数据源头是根本，虽然看起来像是重复定义，但是换个角度，本来我们就是在定义两个源头，只是人家刚好键名一样罢了。
为什么说是两个源头，前端很多组件库的时间组件，返回的都是时间格式，但是传给后端的时候，基本是需要转换的，有的后端可能需要时间戳，有的后端需要"YYYY-MM-DDTHH:mm:ss",有的后端可能需要的只有日期，那么对于你前端的数据就是一种污染。
亦或者是比如前端给后端的数据是数字，但是可能后端的奇奇怪怪原因，只能返回给你字符串的数字，而在前端的input组件中，有的组件设置数字输入框赋值是会失败的，而用同一个类型定义也并不能排查出问题，用ts的意义显得很低。
亦或者是有些后端框架设置出来如果key为空，就不返回key，也有可能是在nginx层面设置的，难道都要在定义的时候加?:吗，在编写代码的时候也不会习惯性的做判空处理，因为空的处理产生的bug问题也是很多的。
缺点1：目前还是要一一对应的去对，做好映射。
但是一次的维护，换来的后续只是转换函数和映射的修改，不需要再去动主体部分的代码，把关注点放在数据层面，即使不会用遍历或者解构来做数据扁平化，也能一个个的xxx=xxx.xxx出来，而你写多了这种难看的代码，自然会去看一些像Array的reduce的一些方法方式。
缺点2：代码量提升
所以我说是一种平衡，用代码减少心情的不愉快复制黏贴，减少全局找代码的烦心，之所以定义转换函数我觉得没什么，就是因为入到不规范的开发流程的时候，你可能表单获取的数据格式和后端需要的格式不一致，有的可能要嵌套一层什么奇奇怪怪的字段，都是要写的，多写两行也没什么
4.不适合|慎用 人群
- 不用ts，纯js就不用一个key到处改
- 不用国际化，国际化导致很多地方其实都有用到，比如占位符替换之类的，表单一般定义的习惯会是xxx.form.xxx字段
- 后端不需要你来处理数据，你要什么格式给你什么格式，遇到这种后端，你花点时间改字段怎么了，后端给的数据拿回来只要加进去是真的巴适
3.4相关纯属个人想法，本文也是想分享一下自己的看法，别骂了，别骂了
