要不要前后端分离?康威定律

原创
2021/04/26 15:21
阅读数 93

现在好多项目 动不动就前后端分离,前端vue,后端java

问题是  是不是所有项目都要前后端分离?(一些需要提升前端性能的除外)

管理项目,使用用户十几人 也值得用前后端分离吗?先不说 前端优势,前端是有优势,可是对于小项目,几十人用的项目 哪里体现了优势?

假设有一个管理项目,总共企业里使用者就几十个人。

如果用前后端分离,那么请问 是不是 需要2个人 一个前端一个后端? 当然有人会说他招一个 前后端都会的,那么请问 前后端都会的工资便宜吗?

那么是不是开发成本维护成本 比不分离要高?维护的时候 是不是还得要2个人?

如果前后端不分离,那么基本上一个后端开发就可以了。

而且调试的时候,是不是 一会vscode 一会浏览器,一会后台 三个端来回检查调试?

 

 

 

打包部署 是不是得部署2个地方?

不分离,无论后台改java还是改页面,都很方便。

另外环境部署 是不是加nodejs ?系统运行故障是不是多了,nodejs 的故障问题?

是不是明显 成本 比不分离增加了?

那么为什么 这样的管理类后台项目 还要用 前后端分离 增加成本?

意义何在? 难道只是赶流行,会了一项技术?

难道项目架构设计的时候 只看技术新 大家都用?怕过时? 而不顾成本增加?麻烦增加?

假设一个这样的项目 人员增加2倍,100个项目呢?你是不是要增加200个人力?

假设 不分离 需要2人开发,分离 需要3人,开发30天,一共90天,不分离是70天,差20人天,假设一共100个项目

那么分离情况,20天*100=2000人天 ,再乘以1500 人天成本= 2000*1500=300万。增加300万。再将一些把 算200万吧

也许200万在这些架构师眼里 不算钱。或者说这家公司有钱 不差钱。

又假设 这样的分离项目 前后端都让你 维护 和只后端不分离让你维护 ,你选择哪一个?你会很热情的选择 前后端分离?不怕苦不怕累多干一些?

总结:普通管理项目 十几个几十个人用,没必要分离。客户才不管你分布分离。

 

 

=====

按照康威定律办就好了, 前后端如果是两拨人, 不要多想一定要分离, 如果是一拨人, 确定前后端是否要分离需要算账 , 收益是它会强制我们按照服务的理念指导系统设计, 将来的微服务也就顺理成章, 代价就是架构复杂了, 开发和运维都有些成本.

康威定律

康威定律(Conway’s Law):“Any organization that design a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. – Melvin Conway, 1968

中文直译大概的意思就是:设计系统的组织,其产生的设计等同于组织之内、组织之间的沟通结构。这是康威第一定律组织和设计间内在关系的一个具体应用。更直白的说,你想要什么样的系统,就搭建什么样的团队。如果你的团队分成前端团队,Java后台开发团队,DBA团队,运维团队,你的系统就会长成下面的样子:

 

相反,如果你的系统是按照业务边界划分的,大家按照一个业务目标去把自己的模块做出小系统,小产品的话,你的大系统就会长成下面的样子,即微服务的架构:

【总结】

到底是什么架构 根据康威定律,如果你的团队人员足够,成本够,那么你的系统就按照这样的结构。比如前后端分离,微服务。

如果你是要做一个未来发展的系统,也许现在人员少,未来估计会增长,那么你可以用 复杂的结构,前后端,微服务等。

这个前提是  在现阶段,你的成本会大,这个你要承担,不要想着又想便宜,又要好。

如果你是个小公司,也就几个人,主要做项目,那么除非客户要求,你们完全可以简单化,降低成本,不需要前后端分离。否则以后你 的项目维护增长太大,

假设一个项目前端一个后端一个,2人维护,假设100个项目,那么前后端分离需要200人力,而不用前后端 节约一半。

如果你想赶潮流,那么你要承担多的成本。除非你不想为你老板节约。

 

 

 

 

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部