if 我是前端Leader，谈谈前端框架体系建设

这期来聊一聊前端框架。

“if 我是前端 Leader” 是个人一个文章系列，说说我人在其位，欲谋其职的一些点点滴滴感悟。跟前端 Leader 只有那么一丢丢关系，干货很少，但老小皆宜，不要被标题给唬住了。

文章大纲

• 什么是框架?
• 前端‘框架’的发展历程
  • 前端框架启蒙阶段
  • 野蛮生长期
  • 前端框架整合期
• 现有的框架都有什么？
• 谈谈前端团队框架体系的建设
  • 第一阶段: 前端工程化 / 基础设施
  • 第二阶段: 应用开发方案整合
  • 第三阶段: 组件体系
  • 第四阶段：打通上下游
  • 将来: AI?
• 扩展资料

什么是框架?

这应该不是我第一次谈‘框架‘了。React 是一个框架吗？ Vue 是一个框架吗？ 严格来讲不是，它们只是一个视图解决方案，这里面算得上是框架的估计只有 Angular。

若是说后端框架围绕着‘数据存储’创建起来，那么前端框架的基础就是视图库，毕竟前端的本质工做就是视图。这是为何前端生态圈通常是围绕着视图库展开的。因此说，前端框架的基础是‘视图’库。

若是跟后端框架(Rails, Django, Laravel...)比起来，成熟的前端框架其实很少。

什么是框架？

看个例子。打开 UmiJS, 它对本身的描述是:

可插拔的企业级 react 应用框架

关键字是企业级。什么是企业级，我本身也说不清楚。我只知道 React 没有说本身是企业级，Koa、Express 也没有，然而 Eggjs 和 Umijs 都说它们是企业级框架；Angular 一般也经常跟企业级这个概念联系在一块儿；语言层面有 Java。

对比一下他们就知道了，我以为企业级表示它是 面向企业生产，目的是提升企业的生产力。总结一下有如下特色：

• 是高效 + 成熟方案的整合
• 关注生产的整个链路，而不是某个环节
• 有更强的约束和限制
• 更严苛的要求。性能、可扩展性(以应对不一样的需求)、健壮性、稳定性、可用性、安全性
• 标准化
• 通过生产环境验证, 有较多用例保证

归根到底仍是成本问题，框架最本质的目的就是要减低各种成本。让更少的人能够作更多的事情、且能保证质量、下降维护成本，且能保证不断优化和演进。

给个定义吧。

前端框架体系的创建离不开前端工程化成熟和‘最佳实践‘的沉淀’。你能够认为框架就是一个整合的方案，提供一个前端‘最佳‘的组合配置。开发者须要作的就是在这个框架约束下填充本身业务代码。

好处：

• 效率提高。让开发者关注业务开发
• 学习成本下降。框架封装了不少底层复杂性
• 更强的约束。全部动做必须按照框架规定的执行, 避免干坏事、蠢事。更强的约束也意味着框架集成度更高、框架内部能够作更多事情，但灵活性也更低。
• 产品质量。框架内部会自动处理不少事情，例如性能优化、安全性处理
• 可维护性。全部项目都按照一致的、标准化的规范开发，升级迭代方便。这一点对团队项目的可维护性很重要。

坏处:

• 灵活性。不能知足全部人的需求，最佳实践这种东西有点武断
• 滞后性。具体方案可能会滞后。
• 大而全。对于某些项目可能太重。

前端‘框架’的发展历程

前端框架启蒙阶段

在 React、Vue 流行以前已经有许多‘前端框架‘，例如 Angular、Ember、Backbone...

它们大部分都受到后端框架的启发，由于当年也正是后端框架最火的时候，例如 Rails。因此在它们身上会看到不少后端框架的影子。

可是不少后端的开发模式，在前端有点吃不开。更本质的缘由是前端工程化还不成熟，基础相对薄弱，难以支撑上层建筑的发展。

野蛮生长期

随着 NodeJS 的普及、JavaScript 语言日益强大，前端工程化逐步深化。 React 这类视图库出来后，不少东西被打碎重构, 正所谓百花齐放，欣欣向荣。

围绕着三大视图库各类各样的库百花齐放，前端也拓展到了浏览器之外的领域。人们都乐于造轮子，使用最新的技术。

因为发展得太快，所谓的框架/最佳实践很难被普遍接受，或者很容易就过期了，每一个人每一个团队更热衷于创造本身的组合方案，每每也只限于团队内部。

前端框架整合期

几乎每一个团队都会重复走这样的路子：稳定技术栈、工程化建设、基础库/组件库建设、沉淀本身的最佳实践。

团队没有必定的工程能力和资源实际上是很难将这些零散的实践体系化、有机地粘合起来, 长期有效的维护更新更是一件难事, 半途而废的居多。

如今前端发展开始进入平稳阶段。因此大一统的前端‘框架’再一次进入人们的视野。就像 Umi 的做者 云谦 说的: 如今是工业化时代, 框架像是一个魔法球，把各类技术栈吸到一块儿，加工后吐给用户，以此来支撑业务。

上图来源于<蚂蚁前端研发最佳实践> PPT

框架就是将各类技术栈方案、基础设施整合起来, 暴露标准的、一致性的接口, 让开发者专一业务开发。

现有的框架都有什么？

一个前端开发框架应该涵盖前端开发链路的各个环节。为约束和简化业务开发、提供有用的指导。

看看现有‘前端框架‘吧，如今社区上比较流行的‘框架’有 Angular、Next.js、Nuxt、Umi。咱们横向对比一下它们的一些特性，发现基本上包含这些东西：

跟衣服的标准码同样。社区开源的都是通用类型框架，能够预知的是它们没有办法知足全部团队的要求。咱们每每须要根据本身业务状况量身定制框架。

为了应对这些需求，不一样的框架也有不一样的应对策略:

• 更开放。框架只提供核心功能，附加几乎什么事情都能干的插件机制。插件能够干预框架的整个生命周期，不知足的需求能够本身定制本身的插件
• 更决断。我给你提供的就是最好的，能知足你的尽可能知足你，其余的你不要管太多，也没有必要管, 专一你的业务。

咱们也有本身的选择策略:

• 本身搞。例如大厂团队，有资源、有丰富的实践经验。他们有能力将本身的‘最佳实践’体系化。他们会选择建立本身的框架。同时他们也乐于将经验分享出来，也能够利用社区完善本身的做品。我的，基于学习和折腾的目的, 也能够搞一套。
• 基于开源框架扩展。能够将开源框架做为基础，根据本身团队状况进行扩展开发。
• 彻底使用开源框架。开源框架能够知足许多通用的需求, 适合简单的应用场景。咱们选择一个框架主要有两个缘由：① 咱们要提升工做效率；② 咱们须要一个标准。 为了标准，其实可妥协一些事情。更重要的是这些框架是在不断发展和演进的, 从而咱们团队的技术也能够免费地跟随他们演进和发展。将开源框架的默认最佳实践开发视为标准。

我一直坚信专业的人作专业的事。要善于将事情外包出去，腾空本身去作重要的事情。大厂有专门的团队在作工具、建设基础设施，社区上开源的框架也由一大帮牛人在维护，并且一般开发迭代很活跃。因此说社区已经有的方案，能够直接拿来用，不要本身去造轮子，由于你通常没那么多精力。

谈谈前端团队框架体系的建设

前端开发的时间都花在了哪里?

上图来源于<蚂蚁前端研发最佳实践> PPT

对于前端团队来讲，开源前端框架只是一个基础，只是涉及前端开发的某个很小的部分，它就像一艘船。你要航线穿越大西洋，还有作不少工做、须要紧密高效的协做、可靠的后勤保障、目标和方向、坚决的领导... 路还很长。

如今来聊聊‘广义的‘框架体系，它集成自身业务，涉及前端开发完整链路，关注点从前端应用上升到了前端团队研发体系。

九层之台，起于累土。 前端团队框架体系的建设是一个渐进式的过程，首先从基础设施开始、接着就是应用开发技术栈组合，再到组件体系，后面是上层的业务开发方案... 上层如下层为基础，共同构建出完整的框架体系。

我以为前端团队能够按照这样的分层结构，分阶段来完成这些建设任务。

第一阶段: 前端工程化 / 基础设施

最基础的阶段，关注前端的基础设施建设。这个阶段已经比较成熟，社区上有不少开箱即用的方案，例如 Umi、Next.js、Vue-CLI、Create-React-App 等等。主要内容有:

第二阶段: 应用开发方案整合

在完善基础设施的同时，团队的应用开发技术栈组合方案也应该稳定下来，成为框架的一部分。这些组合也很是重要，它会影响上层的组件建设和业务开发。主要内容有:

第三阶段: 组件体系

组件化如今是前端主流开发模式，这里还有不少工做能够作，还有很大的提效空间。

整个组件体系也是一个分层式的结构：

• 基础组件。越底层，就说明可复用的程度越高、越通用。Ant-Design、Element-UI、iView、Material-UI 这些就属于基础组件库，有能力的团队也能够开发一套符合本身设计风格的组件库。
• 业务组件。在基础组件之上封装的、耦合本身业务的组件。它们通常从重复的业务场景中抽象出来。
• 区块。再往上，就很难用模块化的组件去组织了。因而有人(阿里前端)提出了‘区块’的概念，你能够认为‘区块’是：代码片断、代码示例、代码模板... 这么看来，这并非一种新的概念? 还没完! 区块还要配套‘区块市场’才能展示它的用处。区块市场是一个代码片断分享平台，维护着大量的区块，试图覆盖大部分常见的使用场景。对于开发者来讲就是找到尽可能匹配本身场景的区块，拷贝过来，稍微改改就好了。这是一种 ‘Ctrl+C，Ctrl+V’ 编程哲学的完美实践啊。
• 页面。和区块差很少，快速生成页面和路由。约定式的路由能够给页面自动化建立带来一些便利。
• 布局。例如后台的总体布局。
• 项目。项目的总体结构。能够经过‘脚手架‘ 来快速生成项目模板。

飞冰

像区块、页面生成这些操做须要一些工具辅助。例如：

• 生成器。生成不一样级别的元件
  • 项目(项目模板)。 俗称脚手架, 支持不一样的项目类型：应用、组件库、程序库、 插件
  • 页面/路由
  • 区块
  • 组件
  • 数据模型
• 可视化工具。可视化的项目编排工具, 如飞冰。

第四阶段：打通上下游

前端只是研发流程的一环，只是前端自嗨，上下游没有资源支持，是很难走远的。

对于前端来讲，一般上游指的是 UI、下游指的是后端。

对于 UI。上面说的组件体系，实际上是创建在稳定的、一致的、统一的 UI 设计语言之上的。不然一切都是空谈。因此咱们要求 UI 设计团队要有良好的设计规范、能和前端组件体系绑定并良性迭代。

对于 后端。能够促进创建更标准的接口范式、封装通用的服务(有利于业务组件复用)、更深的有业务中台、BFF...

上下游的打通，对前端生产力的解放也有很是大的促进做用。

将来: AI?

AI 自动生成前端代码？ 过高大上了，仍是把话筒交给它吧： 《双 11 模块 79.34% 的代码是怎样智能生成的？》， 溜了

(扫码进群限额已到，能够加 blank-carney 备注进群)

扩展资料

• 《蚂蚁前端研发最佳实践》文字稿 好文
• 双 11 模块 79.34% 的代码是怎样智能生成的？