博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
我们前端跟后端是怎么合作的
阅读量:5040 次
发布时间:2019-06-12

本文共 1335 字,大约阅读时间需要 4 分钟。

摘要: 文章背景,来自于群内周五晚上的一次头脑风暴式的思维碰撞交流活动。

我们的流程是这样的,后台提供数据接口,或接口文档。 

然后我们前台进行razor模板的数据逻辑嵌套或html,css,js整个流程的开发。 
缺点是:工作量是满大的,优点是,所有前端view层的东西都是可控的。 
坑是比较多的, 
比如数据出现问题时,没有一个经验丰富的前端或后端进行联调, 
有问题短时间内是解决不了的。

 

一般跟后台合作分为这几种模式:

1. 只产出html页面,然后交给后端来处理数据。
这种的好处是工作量比较少,公司没有专门的前端岗位时可以实行这种办法。
但这种的缺点也是显而易见的,后端人员工作量偏大,如果有ajax或数据添加后出现样式问题,
进行联调,花费更长的时间。

2. 产出静态的php,jsp页面,然后交给后端来处理数据。
这种的好处是因为提交的是php,jsp页面,如果数据添加之后界面出现问题,可以很快的去调整,
方便各种联调,但是最根本的问题是后端的工作量还是稍大,并没有完全的减轻后端人员的压力。
打包发布还是需要依赖后端,而且在开发中依赖后端的情形偏重。

3. 产出动态有数据的php,jsp页面,前端与后端的打包发布完全独立。
这种的好处是前端层的表现,数据完全由前端把控,
有什么问题可以由前端独立解决,并单独打包发布。
缺点是由于前端的工作量加大,对前端的技术存储要求偏高,人力招聘有一定的难度。
由于这种界限的划分有时候很难确定,这时候群内朋友给出的建议是:
1. 公司上级确定,这个活该谁来干 
2. 看公司实际情况,如果FE人少,那么就交给RD 
3. 根据不同的语言来区分对待。

还有其它人的合作方式是:

1、提出需求,讲明白前端要的接口效果。看后台人员是否能满足这样需求,如果有现成的接口,直接调用就是。如果没有,那么就跟后台人员协商是否可以再次开发。评估工作量和完成日期。 
2,有时候后端设计出来的接口不一定能满足所有的需求,也许在某个方法中有个雷,直到自己去调用才知道。就比如批量插入数据,前台可能会循环调用保存,而不是后台批量插入。前台依次来调用是可以完成操作,但是效率是个问题,需要很好的去权衡。
在与后端合作当中,后端没有提供数据接口,如何处理?有以下几种办法:
1. 自己制作模拟数据
这种办法的缺点时,有时候可能会造成api变更时没有及时更新,好处也是显而易见,能够快速的完成前端任务。
2. 使用,模拟数据生成器

其它有坑的地方:

数据的换算时的谨防精度丢失,接口的返回数据不准确,还有配置文件的频繁修改造成的数据不对等。
我们是前端自己模拟所有的数据接口,后端配合我们做接口,反过来了。 
前端只需提供一些配置给后端,比如数据请求地址等等,后端配上就ok

接口通信,文档配合交流 

前后端分工 还不错。

根据上面的探讨得出以下的结论:

1. 前端了解一门后端语言有助于工作效率的提高,是将来的一个大趋势。
2. 前端的逻辑数据完全可以完全分离,也就是可以与后端不同的语言种类。

 


前端开发qq群:348090425 ,禁止闲聊,非喜勿进~!

 

转载于:https://www.cnblogs.com/jikey/p/4118088.html

你可能感兴趣的文章
poi 处理空单元格
查看>>
Android 内存泄漏优化总结
查看>>
luogu4849 寻找宝藏 (cdq分治+dp)
查看>>
Spring Cloud微服务笔记(五)Feign
查看>>
C语言键盘按键列表
查看>>
Codeforces Round #374 (Div. 2)
查看>>
oracle数据类型
查看>>
socket
查看>>
Vue中使用key的作用
查看>>
二叉索引树 树状数组
查看>>
日志框架--(一)基础篇
查看>>
Java设计模式之原型模式
查看>>
Spring学习(四)-----Spring Bean引用同xml和不同xml bean的例子
查看>>
哲理故事与管理之道(20)-用危机激励下属
查看>>
关于源程序到可运行程序的过程
查看>>
wepy的使用
查看>>
N3292系列资料之RTC介绍
查看>>
System.ValueTuple 未定義或匯入預先定義的類型
查看>>
Redhat6.4安装Oracle 11gr2 64位 注意事项
查看>>
rpm
查看>>