写在前面
年关将近,这年味愈加的浓烈了哈,似乎无心工作,似乎家乡的叨念从远远的方向传进了你的心里,坚持住哈,马上,就回家了。
进入正题,首先,我需要先解释下这个标题所表达的意思,以及它背后引出的具体的问题,前端架构与具体的应用的矛盾 这句话为什么要这么说,相信大部分公司,不论你是创业型公司、外包公司或者是大一点儿的,上市的,在你们的前端技术栈中,react出现的频率应该不低,vue是更甚者吧,基于webpack、glub构建的应用应该很多了,甚至可以说,这些技术已经占领了前端的半个天下,但是笔者在这里呀,不禁要提出一个问题,那就是,你们的技术栈真的带给前端更简单的内容了吗? 使用这些技术栈的时候,你们的应用是否会变得学习成本高昂、扩展能力差、依赖高阶程序员、文档不齐全、有没有测试用例?
架构的本质
我认为架构的本质应该是什么? 它应该是基于可能面临的风险构建的一套能够适应当前业务、扩展未来业务、行为可预测的、高可用性的。在能解决这些问题的前提下,架构应该是高度抽象的吧,一个优秀的架构,它一定要足够简单,基于一个或多个抽象的理解上构建出来的。
简单才是本质,spring为什么那么火,它足够简单。一旦你了解了它的抽象思维方式,整个开发极易上手,这就是一个优秀的架构应该有的表现力。如果你正在设计前端架构,我的忠告是,最好结合你的业务实际去实现它而不是去考虑最新的技术栈,盲目的追求渲染速度、组件式等。
前端一定要与业务接轨,一个管理系统,你跟我谈什么渲染速度?一个正常的管理系统前端,它甚至都不需要webpack这样的工具构建,只需要一个裸的vue加上jquery就可以完成,这样的结构要优于大部分。为什么? 贴合实际嘛! 后台系统你一个前端能维护多久呢?大部分时间,后台er在维护这个界面,如果你使用的技术太过复杂,增加了学习成本,还更容易使整个架构逆向发展。
再例如,企业官方网站,企业商城,大型公司的门户,宣传网页,这些东西完全不需要用到打包、甚至vue你都要少用, 为什么?最重要的是它们不利于SEO,然后是不利于快速迭代,设计的再复杂些,vue技术栈全部捅上去,那有什么用嘞?除了给你自己的职业生涯添加一笔,对公司来说这就是技术的债务,公司需要招比你更厉害的人才能理解你写的这些高级的代码,而这些代码一旦在无数个迭代中膨胀,最后的选择只有推倒重来,改都没的改。
结合业务再谈技术
什么前端路由系统,SPA 框架,你都要结合业务,后台系统使用SPA就是耍流氓。陡然增加前端的复杂性,让前端变成了一个比后台系统还复杂的系统。这很得不偿失。仅仅是为了前端开发的便利性,忽略的整个系统的复杂度,这样的架构怎么看都是不可取的。
什么时候能够使用这些技术栈? 当然是业务允许、风险可以控制的情况下。 例如多终端,移动端,在移动端使用打包工具,SPA框架开发是很明智的,它们带来的优势,在渲染速度上,在使用性上,都是一流的。而且真正的实操中,这样的项目一般是重点维护的。
要结合业务的实际选择技术,大部分时候,开发时间是有限的,实现的功能很多,盲目追求技术的新、快、是没有根据的。
一些看法
推荐一些我个人开发时常用的几项前端架构,它们是我结合平时的开发实际,业务适应程度做出的技术栈调整。
首先,如果项目大小一般,时间很紧急,我会毫不犹豫选择裸vue+jquery+bootstrap,快速开发完毕。
如果项目中等的话,时间不多不少,我会看团队中,开发人员的比例,比如这个开发团队只有一两个前端,那么我会选择 require管理我的js模块,使用sass管理我的css模块,足够模块化,也有组件,同时开发速度够快,团队中的其他人理解起来也很快,在项目很赶的时候后台也可以帮一些忙,也不会担心他们破坏架构。具体到业务逻辑,首先了解业务的流程,例如我这个应用,面向的是企业管理人员,可能需要一些大数据展示,一些图形化界面。那么我很可能选择react+react-router+redux。
大型项目需要依靠具体面临的可能风险,你需要调研清楚目标人群,宣传方式,例如使用SEO做搜索宣传,就不能选择打包技术,微信wap,选择vue技术栈是明智的选择等等。
需要注意的是,最终的简单才是王道。
写在最后
希望大家一起探讨这方面的话题,我的观点也许是错误的,或者是有问题的,讨论一下,大家一起提升。
======================================================== 转载请注明出处。