前后端工程师工作协同工作主要环节在于数据交互与业务流程控制。

       在数据交互方面遇到这种情况，前后端工程师一开始没有沟通好数据交互格式，因为后端做得快，已经写完接口，出了接口文档，而前端工程师在开发的时候使用了一些框架或者是一些插件，而框架的接口数据有规定，但是后端出的接口数据与前端开发所需要的接口数据不一样，这时候前端工程师就处于被动状态，临时解决问题方法只有三个：

        一、把后端传过来的数据在前端再转化一次，转成框架需要的接口数据。

              缺点：加大了前端开发时间，影响前端页面性能。

        二、前端重新自己写一套前端组件，根据后端接口读取数据。

              缺点：加大了前端开发时间。

        三、让后端工程师根据前端框架的接口数据重新写接口。

              缺点：加大了后端开发时间，影响后端数据处理。

      想想都知道，后端工程师肯定不愿意重写接口，后端工程师就说会影响很多代码，苦逼的还是前端工程师。前端工程师只能一步一步重新改造前端页面。

      在业务流程控制方面遇到这种情况，前后端工程师一开没有明确的分工，前端工程师一直负责view方面，后端工程师一直负责model方面，中间的control方面没有处理，结果到前后端项目合并就出现了问题。中间一个业务控制层没有了。项目某些地方业务无法处理，后果可想而知。临时解决问题方法只有两个：

        一、前端进行业务流程控制。

              缺点：加大了前端开发时间。纯静态技术实现会导致部分页面数据不安全，容易丢失数据，不能为用户提供动态数据。（胖客户端-瘦服务器）

        二、后端进行业务流程控制。

              缺点：加大了后端开发时间。（瘦客户端-胖服务器）

      想想都知道，后端工程师肯定不愿意重写业务控制层，后端工程师就说会前后端分离，减轻服务端压力。苦逼的还是前端工程师。前端工程师只能一步一步重新添加control层代码。

      综合上述，这个坑永远还是前端工程师填。那么如何解决以上两类问题呢？答案其实很简单，这两类问题产生的主要原因是缺乏沟通。因此，在项目开始的时候一定要沟通。前端工程师一定主动要向后端工程师说明使用框架所需要的数据接口格式。并且一定要分工明确，搞清楚前端负责哪些部分，后端负责哪些部分，业务流程控制需要前后端如何配合。这样才能避免以上两类问题，从而影响工作进度。（说白了就是为什么要加班）