提升前后端联调开发效率

[noneven]

1、写在前面:

前后端分工协作是一个老生常谈的大话题，很多公司都在尝试用工程化的方式去提升前后端之间交流的效率，降低沟通成本，并且也开发了大量的工具。

2、传统前后端开发流程

前端切完图，模拟后端接口数据，处理好接口信息，接着就是把静态资源交给后端组装(套模板)，这是一般的前后端开发流程。这种流程存在很多的缺陷next。

3、 存在的问题

• 后端同学对文件进行拆分拼接的时候(公共头部/尾部抽离等)，由于对前端知识不熟悉，可能会搞出一些BUG，到最后又需要前端同学帮助分析原因，而前端同学又不是特别了解后端使用的模板，造成尴尬的局面。
• 如果前端没有使用统一的文件夹结构，并且静态资源（如图片，css，js等）没有剥离出来放到 CDN，而是使用相对路径去引用，当后端同学需要对静态资源作相关配置时，又得修改各个link，script标签的src属性，容易出错。
• 接口问题，后端数据没有准备好，前端需要自己模拟一套，成本高，如果后期接口有改变，前端又要修改已经给后端处理好了的模板，接口的变动使得前端和后端有需要重新沟通。

4、解决方案

为了解决传统开发模式的一些问题，很早前Facebook就提出了SPA（single page application）解决方案，前后端职责相当清晰，后端给前端接口数据，前端全部用 ajax 异步请求(SPA也有一些弊端,这里就不详细讨论)，再由前端渲染页面。

上面👆提到的SPA的关键在数据，数据交给谁去处理？在我们的团队中数据的约定首先由前端根据UI+UE出一套接口文档并同步到一个前后端都能访问的接口平台：接口平台支持JSON导入导出方便编写文档

然后由后端和前端做一次接口评审(拉上PM)，后端指出前端给出的接口数据有哪些不恰当的地方，最终产出一个前后端都认可的接口文档(V1.0)，后面前后端就按照这个V1.0各自进行开发，前端可以通过json-server等开启模拟接口开发页面和交互，当后端接口完成时，前端把模拟接口去掉直接走后端的接口数据进行联调测试。当后端/前端需要变动接口的时候，在接口文档里面修改接口生成V1.1周知后端即可。
同时这样也可以让测试童鞋在项目提测前就介入部分接口测试，让整个项目并行。

转载请注明出处

[noneven]

一个后端工程师对前后端接口约定的看法(仅供参考)

• 工作模式
  公司目前采用前后端分离的模式进行项目开发。本人处于后端组的Java开发职位。
• 前后端的沟通桥梁
  前后端分离开发项目，前端组主要负责页面的设计与交互，后端组主要负责数据的存储与服务。前后端组工作协作靠接口文档。目前本人公司的接口文档由前端工程师主要填写，后端人员进行后期的调整。
• 发现的问题
  在前后端两个小组协作开发项目的过程中，逐渐了发现了些许协作问题，以本人目前的眼界，认为最为突出的问题会发生在接口文档上。
• 结论缘由
  为什么本人会认为最大的问题出现在接口文档，并在此请教改善之法呢？有以下几点原因。
  • 1.前后端人员的思维差异
    接口文档，表明了前端请求后端数据时的格式。本人公司采用json的数据格式进行数据交互，后端采用Java开发，自然是将model中的数据转为json格式“跪送”给前端。但由于每个人的思维不用，对接口中的字段命名习惯等也大不相同。例如后端User类中有name和age两个属性，但前端人员写接口文档时偏偏是{“username”:“xxx”, “sex”:“xxx”}。为了应对这种情况，最开始开发项目时，后端再返回数据之前采用Map的方式将model中的数据进行重组和封装，达到前端要求的接口内容。但Java代码就泛滥出大量的put操作，甚是繁琐。个人认为这种情况可以在开发前期两组就要办法做统一规范。
  • 2.前端人员填写 接口的“随意性”
    为了避免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. 过于过程化的接口结构
     第三点是我近期所察觉到的最可怕的一点。诸如上述问题的存在，当遇到复杂的项目时，文档结构就会失控。假如前端人员对后端的技术并不清楚的话，以及他们更偏向于过程化的编码思维，直接导致接口结构呈现过程化的趋势，可悲的是由于交互功能的复杂度，后端为了实现前端期望的接口结构，在编码时已然潜移默化地在进行面向过程的开发，而不是面向对象，个人认为这是灾难的征兆。说到这儿，我依旧不认为前端在写接口有错或是有问题，这是人家的正常思维习惯。
     以上是本人在自己工作经历中所感悟的痛楚，在此请教各路有经验人士的改善观点。在这里

[noneven]

接口平台开源的可以用
swagger
RAP

不过基本上所有的大厂都会有自己的一套接口文档编辑平台