工作模式
公司目前采用前后端分离的模式进行项目开发。本人处于后端组的Java开发职位。
前后端的沟通桥梁
前后端分离开发项目，前端组主要负责页面的设计与交互，后端组主要负责数据的存储与服务。前后端组工作协作靠接口文档。目前本人公司的接口文档由前端工程师主要填写，后端人员进行后期的调整。
发现的问题
在前后端两个小组协作开发项目的过程中，逐渐了发现了些许协作问题，以本人目前的眼界，认为最为突出的问题会发生在接口文档上。
结论缘由
为什么本人会认为最大的问题出现在接口文档，并在此请教改善之法呢？有以下几点原因。
- 前后端人员的思维差异
接口文档，表明了前端请求后端数据时的格式。本人公司采用json的数据格式进行数据交互，后端采用Java开发，自然是将model中的数据转为json格式“跪送”给前端。但由于每个人的思维不用，对接口中的字段命名习惯等也大不相同。例如后端User类中有name和age两个属性，但前端人员写接口文档时偏偏是{“username”:“xxx”, “sex”:“xxx”}。为了应对这种情况，最开始开发项目时，后端再返回数据之前采用Map的方式将model中的数据进行重组和封装，达到前端要求的接口内容。但Java代码就泛滥出大量的put操作，甚是繁琐。个人认为这种情况可以在开发前期两组就要办法做统一规范。 - 前端人员填写接口的“随意性”
为了避免Map方式所带来的繁琐操作和put代码泛滥，随后的项目开发中，引入了DTO类，并借助Dozer工具进行实体类DTO类之间的映射转换。DTO类中的属性名符合前端人员在接口文档中所写的字段名称。例如为了传输User类的数据，对应的有UserDTO类，有username和sex属性。同时DTO也可以应对传输实体类部分属性的情况。OK，这种模式进行了一段时间后发现，由于前端人员写接口太过随意，导致后端会产生大量碎片化的DTO类。举个详细的例子：
public class Course { //课程实体类
private Long id;
private String number;
private String name;
private Teacher teacher; //课程教师
}
前端通过接口请求课程相关的数据时，可能是{"number":"xxx","name":"xxxxx"}，可能是{"id":xxx,"name":"xxxx"}，亦或是{"id":xx,"name":"xxx","teacherName":"xxx"}。这种“随意性”导致后端要么创建应对各式各样情况的DTO类，要么就是在实体类和DTO类中追加冗余的、没有意义的属性。例如又可能为了显示，需要在Course类添加一个studentScore的属性。
当然“随意性”我用了引号，表示这只是我个人的观点，并不能说明前端人员有错，人家在写文档时自然更偏向于自己认为舒服的结构，这很正常，本人表示充分理解。
3. 过于过程化的接口结构
第三点是我近期所察觉到的最可怕的一点。诸如上述问题的存在，当遇到复杂的项目时，文档结构就会失控。假如前端人员对后端的技术并不清楚的话，以及他们更偏向于过程化的编码思维，直接导致接口结构呈现过程化的趋势，可悲的是由于交互功能的复杂度，后端为了实现前端期望的接口结构，在编码时已然潜移默化地在进行面向过程的开发，而不是面向对象，个人认为这是灾难的征兆。说到这儿，我依旧不认为前端在写接口有错或是有问题，这是人家的正常思维习惯。
以上是本人在自己工作经历中所感悟的痛楚，在此请教各路有经验人士的改善观点。
虽然我没经历过这种调用者来制定接口文档的工作流，但我觉得问题的核心在于接口的制定两方应当有平等的发言权，不能一方拍板说这样就这样
比如model里字段名叫
name，就不能允许接口叫username，除非所有model就把名字也改成username。两个接口对同一个model同一个字段的命名不一样，不仅后端会疼，前端也迟早掉坑，对大家都没好处
具体到题主的实践中，我觉得一个改善的方法就是前端出的东西把它认为是“接口需求”，后端人员拿到以后在一定的原则（比如保证cover需求）之下进行修改，出第二份“接口文档”，再给前端人员评审一遍之后达成共识，成为最终的接口文档。
还有你的思考很好很对，应该和你的老大商量，甚至拉前端老大来商量
最后，平时多搅基多饭醉，前后端分离是技术上分离，可不能在感情上也分离