前后端分离的罪与罚

什么时候开始吹起了前后端分离的风,在我的回忆里是应该随着 One Page Application 的风来的,突然有那么一段时间 Vue,Angular,React就像雨后春笋长出来一样,前端离开了后端也可以玩转整个处理的流程了,工种的区分的也慢慢的变成前后端两只岗位了,甚至于过了一段时间出现了 Fullstack 的开发者。

为什么会需要前后端分离

原因也很简单,现代的IT技术已经非常的复杂,需要专人专岗了,年轻的朋友们可能已经没听过 Web2.0 了,让我们温顾一下:

Web 2.0,指以最终用户为目标,强调用户生成内容、易用性、参与文化和互操作性(如:与其它产品、系统和设备兼容)的网站。

在那样的时代,我们几乎使用 JQuery 就可以完成大部分的情况了,但是我们迎来了移动互联网时代,大部分的用户都在手机上进行操作,我们并没有像是BS架构这样的技术直接在手机端使用(当然后面也有一些 HTML View的技术),手机端的数据需要进行和服务器端进行交互,并且此时的Web页面也正在变的复杂,那随之而生的也就是现在大家所能见的 前后端分离 的兴起。

前后端分离是银弹吗?

软件工程没有银弹,前后端分离带来的优点包含

  • 专人专岗:提高了单位输出效率
  • 降低门槛:以前要学的现在只要学一半
  • 接口复用:现在提供的接口可以进行复用
    能够显而易见的好处大致上有这些,那它的缺点呢,我们显然也不能避而不谈。

沟通成本

对于绝大多数的公司来说,沟通成本本身就足够大,而现在通过刚性的手段将前后端分离,前后端之间通过脆弱的API文档进行沟通本身就是不可靠的,对接过支付宝接口之类的同学也都明白,往往仅有一个API文档依然不足够,还需要有足够多的说明的与Demo,如果寄希望后端补齐这些东西,那增加的时间成本又甚至于高于分离的之后减少时间成本,因为对于大部分的公司来说,前后端分离意味着需要花更多的时间进行API层面上的沟通,如果是相互熟悉的团队可能经历了数个周期的磨合之后会有好转,标准化是一个办法,但标准化往往本身就足够困难。

信息隔离

对于后端来说如果仅仅做后端不考虑前端的实现,往往会写出一些看上去完美的接口,但是实际上在最终和前端对接的过程中,前端同学会心态爆炸,比如对于某些计算值是否都需要前端计算,为什么这个值还要再请求一次,而前端在倒逼后端的时候,后悔的同学也往往会困扰,为何要做这么冗余的设计,而这一切本身都无错,前端是视觉驱动:从展示的元素中提炼对象,而后端是数据驱动:从业务逻辑中提炼对象,这两份对象常常不同意,前后端分离的解决之道是增加一个中间层,无形之中又增加了复杂度。

真实之道

摒弃狭义的前后端分离(仅仅将前后端开发者分离,恰当的说法可能是分家),而是按照 产品线基础设施 分离,对于产品线来说,绝大多数不应该分离前后端职能,从应用的架构上,可以将前后端分离,但是对于某一产品功能应该采用 E-E 端到端的模式,无论是页面展示还是后台数据的存储调用,都应该由单一责任人进行开发。而对于基础设施处,几乎都是数据驱动的技术性产品,这段可以采用完全的前后端分离,为专业人士排除其他的压力,除此之外,也就是极其复杂的UI页面应该由专业的前端进行开发。

最终构成一个形如网吧的办公场所,人人的技能都可以在相互交流中增长。
3AK5nO.png