写在前面
年关将近, 这年味愈加的浓烈了哈, 似乎无心工作, 似乎家乡的叨念从远远的方向传进了你的心里, 坚持住哈, 马上, 就回家了
进入正题, 首先, 我需要先解释下这个标题所表达的意思, 以及它背后引出的具体的问题, 前端架构与具体的应用的矛盾 这句话为什么要这么说, 相信大部分公司, 不论你是创业型公司外包公司或者是大一点儿的, 上市的, 在你们的前端技术栈中, react 出现的频率应该不低, vue 是更甚者吧, 基于 webpackglub 构建的应用应该很多了, 甚至可以说, 这些技术已经占领了前端的半个天下, 但是笔者在这里呀, 不禁要提出一个问题, 那就是, 你们的技术栈真的带给前端更简单的内容了吗? 使用这些技术栈的时候, 你们的应用是否会变得学习成本高昂扩展能力差依赖高阶程序员文档不齐全有没有测试用例?
我认为架构的本质应该是什么? 它应该是基于可能面临的风险构建的一套能够适应当前业务扩展未来业务行为可预测的高可用性的在能解决这些问题的前提下, 架构应该是高度抽象的吧, 一个优秀的架构, 它一定要足够简单, 基于一个或多个抽象的理解上构建出来的
简单才是本质, 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 技术栈是明智的选择等等
需要注意的是, 最终的简单才是王道
写在最后
希望大家一起探讨这方面的话题, 我的观点也许是错误的, 或者是有问题的, 讨论一下, 大家一起提升
来源: https://www.cnblogs.com/ztfjs/p/software_2.html