开发一个大型后台管理系统，应该用先后端分离的技术方案吗？

话说这天，咱们团队开会讨论了一个问题，不，与其说“讨论”，不如说“争吵”更合适。

背景是这样的：

咱们要开发一个 xxx 后台管理系统，这个系统业务复杂、功能又多，你们的争吵集中在“这个系统是否应该用先后端分离的方案”。

此次争吵的问题比较典型，因而我就写了这篇文章。为了你们好理解，把“xxx 后台管理系统”泛化一下，变成：

开发一个大型后台管理系统，应该用先后端分离的技术方案吗？

先说一下，本文中的观点确定有人不认同，再加上我对前端技术掌握有限，因此你们批判的看吧。

1. 先审题，冷静的分析一下

先后端分离的优势多多，这不须要多说，你们人人都清楚。

来，讨论以前，咱们先一块儿好好审审题。

结合“开发一个大型后台管理系统”这个约束条件，冷静的分析一下：

• 什么是后台管理系统：首前后台管理系统这个称呼，意味着这是一个 B 端系统。能够小到部门级应用（客户投诉登记系统、办公设备台帐系统），大一点能够是大集团级核心系统（500 强保险公司客服、呼叫中心），能够是 ERP、CRM、OA（SAP、用友、泛微协同），能够是一个 B2C 电商的商城后台、支付网关管理控制台，能够是 Saas 的管理后台（Salesforce、Teambition、Jira），能够大到阿里云控制台……

• 什么是大型：我理解大型系统是指功能模块多、交互复杂，而不是访问量、TPS、数据量大。因此 CMS、OA、ERP、CRM、阿里云后台、呼叫中心等各类管理系统，知足功能多、逻辑复杂，基本能够称为大型系统，虽然他们体量和交易量可能不在一个量级。另外大型系统基本等价于“维护周期长，需求不断变动”，这个在后面维护成本部分阐述。

• 性能考量不是主要决定因素：由于咱们这里讨论的是 B 端系统的前端技术选型，所以个人观点是性能不是主要考虑因素，由于性能瓶颈每每在后端和数据库，其次 B 端产品少有爆发性交易量（秒杀 大促 活动），最后 B 端产品不强调首屏渲染速度。

• UI 操做效率是最主要考核指标：B 端系统产品都是用来干活儿、管理、生产调度的，操做效率和方便性大于天。屏幕空间要充分利用，减小切换跳转弹窗；快捷键效率远高于鼠标；SPA 多页签布局有利于保持工做上下文和状态；必要时能够鼠标右键菜单操做；功能菜单操做提示要清晰易理解，减小培训麻烦；在此基础上，尽可能减小每个界面上呈现的信息量，只呈现最少的必要信息，下降用户认知压力。

• UI 开发效率高、维护成本低是关键考量因素：大型系统基本等价于“维护周期长、需求不断变动”，所以在技术选型上尽可能要求维护成本低、学习成本低、招聘容易、组件化程度高代码简洁……

• UI 颜值美观度不是关键考量方面：界面简洁大方、图表丰富、数据展示清晰，这其实自己就是一种美——朴素实用的美。

• 浏览器兼容性：这条要看具体状况——Saas要求兼容性高；内网系统、内部系统能够要求浏览器产品和版本。

2. 亮观点

基于上述，因此个人观点就是：

先后端分离对于大部分“大型后台管理系统”来讲弊大于利。

大型后台管理系统，相对于 C 端产品，B 端产品隐含等价于“业务逻辑复杂”。我不是说 B 端比 C 端产品难作，C 端有另外的难度（好比用户体验、好比竞品之间的竞争更加激烈、好比并发量挑战、好比作活动的需求频繁……）。

一般来讲，复杂业务逻辑的产品须要产品、美工、开发各工种人员，密切配合、快速原型、MVP、快速迭代、快速试错。所以，由后端工程师全栈开发的效率、效果，要高于先后端分离（这里说的“效果”指的是趁热打铁和技术主观能动性的效果）。

那种“产品画框图、再到作设计稿、再到前端切图、最后扔给程序员渲染模板”的传统开发流水线，会完全拖慢一个业务需求从想法到交付的周期，会完全割裂整个团队，会遗漏大量的上下文信息，会增长巨大沟通成本，会完全磨灭项目成员的参与感和对产品的归属感。

画图仔、切图仔和码农，循序渐进像流水线拧螺丝同样开发产品，很难建立出一个有灵魂有灵性的产品！

更不用提早后端分离形成的开发、联调、部署、定接口、维护接口的成本提升。

另外，先后端分离也不适合项目型公司，由于项目周期有限，团队磨合的时间越少越好。还有，项目交付后，留守的人员配置不齐，致使需求变动和维护问题难以解决。

综上：先后端分离的开发和部署模式，不太适合“大型后台管理系统”，缘由 一方面是上面列举的种种弊端，另外一方面是大型后台管理系统没法享受到先后端分离的好处：Nginx 分开部署的优点、专业前端优点（C 端产品追求极致的颜值和用户体验）。

既然这么多弊端，为何还有不少“大型后台管理系统”之类的项目，跟风搞先后端分离呢？

答案主要集中在两类：简历驱动的技术选型、盲目跟风。

3. 简历驱动的技术选型

软件开发绝对是个良心活儿，跟医生、教师同样的。

我这几年见到了太多的微型团队（10人如下）搞微服务架构，以及先后端分离的 CMS 内容管理系统！

见了太多为了用时髦技术而盲目选型的事情，太多不计后果、不计成本的追求新技术来美化本身简历，太多用流行技术名词忽悠本身不懂技术的老板、上司的状况。

大家的良心不会痛吗？

当你在简历上加上了一个个流行技术关键词，而后拍拍屁股离开了一个烂尾的项目、一个预算严重超支的项目，让创业团队多走几年弯路甚至夭折，你的良心和职业素养都破产了！

你正在透支技术人这个群体的社会声誉。

技术人的天职，本应是把复杂模糊的现实世界问题，建模成清晰逻辑结构化的计算机软硬件，让世界变得更简单高效，若是由于一些奇怪的缘由而把简单问题复杂化，那就是背离了这个行业的初衷。

但愿愈来愈多的甲方、非技术出身的高管们明白一个道理：

靠谱的人是把解决方案作的很简单以致于明显没有问题，不靠谱的人会把解决方案作的毫无必要的复杂以致于短期内看不出明显的问题。

4. 先后端分离不是坏的，跟风才是坏的

先后端分离的出现和存在，固然有它的合理性和优点。

这里插一句，提及先后端分离，必须先介绍一下 Angular、React、Vue，绝对是前端领域的三大当红花旦。可是这三大花旦，也让无数码农陷入选择困难症，引起了大量无休无止的争论。不少讨论，当事人已经忘记了讨论的初衷和边界，最后陷入无心义的口水战。

看看谁创造了它们——谷歌的 Angular、Facebook 的 React、阿里的 antd、饿了么的 element、前谷歌程序员尤雨溪建立的 Vue。

总之就是大厂在创造和使用这些技术，这些技术能解决别人的问题，可是不必定能解决你的问题。

彼之良药，汝之砒霜。

因此我建议：在先后端分离、前端技术选型这种问题上不要盲目跟风，不要以为跟着互联网大厂走就必定不会错。你须要清楚你的项目类型、团队结构、技术沉淀、开发周期……

若是你和大厂同样，不差钱、不缺资源，那没的说，尽管选最好最贵、对标一线大厂技术栈，甚至是直接从大厂挖人。

若是你是作项目赚辛苦钱，或者本身投资研发产品，在传统行业、在产业互联网精耕细做，慢慢摸索培育市场，不在风口不受风投追捧的，那我以为你须要务实一些。

我建议各位本着务实和诚实的态度、职业精神操守，结合本身公司、团队、资源、项目、业务需求，选择最适合本身的技术栈。

但愿这篇文章对你帮助，有不一样观点欢迎经过公众号和我讨论。