作者:核桃大号
https://www.cnblogs.com/hetaojs/p/10616773.html
前后端分离现在火了很多年,在实际中新技术的使用一般是先在一些大厂中采用,比如在招聘网上大厂的前端招聘node要求比较高,而在中小型厂中对node的要求只是会用webpack打包工具以及npm包管理就可以了。最近几年传统公司、中小型公司开始构建前后端分离模式,前后端分离的好处网上文章很多,简单说前端可以专注前端的开发,后端专注后端开发,开发效率和质量都会得到提升,但在实际项目组中因为很多leader资历比较老,思维方式还是传统的软件开发的思维,所以构建出来的团队只是前后端分离的形。我分享下我转前端以来待的3家公司前后端分离模式踩的坑,也自己整理总结下前后端分离模式中要提前做好的协调和准备。
正式转前端,第一次接触前后端分离
我之前是做.net,做的项目大部分是后台管理系统,那时候没有分前端后端,一般是一个功能从数据库到前端一起做,所以工作按时间分布一半时间敲C#代码一半时间写js,那时候后台管理对页面美观的要求不高考虑开发效率所以一般都是用extjs、jQuery easyUI以及后面出来的bootstrap把样式封装好了,只要用里面的组件拼接页面实现业务逻辑就可以了。但随着C#在市场的需求越来越少,开始感觉到危机,考虑要不要转行。那时候在开发群认识一个大佬招前端Vue,当时Vue刚出来没多少久,很难招到人只能改变招聘要求找原生js基础相对比较好的,就这样我进入了这家创业公司也正式进入全职前端行业。这家公司后端3个人前端3个人,前后端的比例1:1。
因为团队不大而且前后端框架都是开发老大搭建的,对前端和后端都有所了解,所以前后端合作的矛盾没有那么突出,但也有些问题和矛盾,这些矛盾在我后面两家公司凸显的更加明显。
- 接口文档在开发的哪个阶段出来。这家公司的模式是边开发边出接口文档,也就是开发完一个出一个,这种方式的缺点在后面详细说到,因为团队不大所以导致的现象不突出,没有成为开发效率的主要限制因素,但也会出现前端没事情做等后端接口文档,开发完之后前端bug比后端多一些。
- 用前言vue1.0开发,开发中很多不方便和坑,2.0做了很多优化,太注重组件的复用,想把所有差不多的都封装成一个组件导致if太多太过复杂难以维护。
- 接口文档在开发的哪个阶段出来,接口文档出来的时间点也是和上家一样,但是因为工作量大、团队大导致这点是开发效率的主要限制因素和后面出一系列矛盾出现。直接导致的问题是开发前期前端只能做静态页面,中期一直在等后端出文档,有些比较负责的前端就会不停的追问找对应模块的后端,问他打算这块返回的数据格式是什么样的。所以经常看到有几个前端经常往后端跑,后端有点烦没好气的说我现在没空或者心情好点话就讲一下。
- 因为写完接口出文档,导致快到提测时间节点上是前端最忙的时候要敲后续的处理数据相关的代码,因为时间比较紧所以先把大概功能处理完就提测,导致测试那边反应前端不细心,细节问题一大堆。
- 基于上面原因,老板询问项目进度每次都是后端做完了,前端没做完,说前端进度慢,bug还多,前端背锅。
- 程序员天生抗拒写文档,所以经常出现文档字段说明不详细(遇到牛逼的理由是看英文单词就知道什么意思啊),前端字段理解没到位所以经常出现字段绑定问题的bug。
- 人的天生惰性,联调前端调用后端接口,测试接口都交给前端,后端写完就不管了。
- 业务处理的前后端分工不明确,主要看后端领导的性格,后端领导在公司地位高些,后端领导是怕麻烦那种性格,麻烦的处理前端能做竟然给前端,前端不能做才给后端做,没考虑过浏览器的处理能力、带宽限制、安全性因素(讨论中后端老大曾说也不会把浏览器搞死机,也就是只要浏览器不死机就行)
- 前端团队平均技术水平不高(毕业不久的占比大)
- 前后端沟通成本较大,后端很多没做过前端,前端很多没做过后端,沟通解释时间较长,前端对项目的业务逻辑理解不深,后端对接口文档不重视不知道接口文档对前端的重要性。
欢迎关注《前端技术江湖》
慎独、勤思