作者：易师傅 、github

声明：文章为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！

前言

大家好，我是易师傅，一个专门搞前端的搬砖师傅 ~

话说当下，前端职位在近十年的磨砺之下，已是百花齐放万家争鸣，前端也不再是以前那个单纯的切图仔；

要问为什么不单纯，无异于 前端工程化、前端 devops、前端跨端、前端工具化、前端 CI/CD、前端 BFF、微前端 这些技术的出现，然而这些日新月异的技术聚合，咱们可以称其为 前端基建；

其实无论您是想成为 高级前端工程师，还是一名 合格的 Leader，都离不开对 前端技术与业务的基础建设沉淀；

看完全文，我相信 您的收获会远不止于此 ~

一、什么是基建？

基建 这个词无论身处哪个行业，基本都会存在；只是在最近几年的软件计算机行业中尤为流行；

在建筑行业：一幢大厦所需的地基，脚手架，一块砖、一片瓦、一袋水泥、一扇窗等等咱都可以称之为基础建设的一部分；

在汽车行业：一辆汽车所需的车架子、发动机、车轱辘、方向盘、门窗等等咱也可称之为基础建设的一部分；

那么在互联网软件行业呢？

笔者的理解是：在软件行业，站在广义的角度上来讲基建包含了：业务基建、工程基建、前端基建、后端基建 等等；（此处仅笔者个人理解，如果意见不一样，以你的为准）

业务基建？

业务基建 是指公司某个业务团队层面所维护的 前端基建、后端基建、基本规范文档、产品规则、设计规范、研发流程、测试边界、上线标准以及业务中台 等等的建设；

业务基建 服务于整个业务团队

工程基建？

工程基建 指的是业务团队内所有工程师的的一些 编码规范、api规范、前后端协作、环境部署、微服务、微前端、性能、安全防御、统计监控、可视化 等等的建设；

工程基建 服务于整个工程团队；

前端基建？

前端基建 指的是业务团队内的前端工程师执行的一些基础建设，包括了 前端规范文档、前端脚手架、前端模板、前端组件库、前端工具库、前端BFF、前端CI/CD的构建部署、前端数据埋点 等等；

前端基建 仅服务于前端团队；

后端基建？

后端基建 指的是业务团队内的后端工程师执行的一些基础建设，包括了 后端规范文档、后端模板、安全、日志、微服务、RESTful API、中间件、数据库、分布式、权限控制、服务器性能并发 等等；

注意：后端基建 仅服务于后端团队；

关系图

看到这里，咱们已经明白了公司基建的一些基本分类和概括，下面我们也主要介绍下本文的主题前端基建；

二、为什么要做前端基建？

场景复现

场景一：

场景二：

场景三：

前端基建意义与作用

• 业务复用；
• 提升研发效率；
• 规范研发流程；
• 团队技术提升；
• 团队的技术影响力；
• 开源建设；

三、前端基建如何推动落地？

技术基建简要流程

要说 前端基建，最主要的难点莫过于如何去推动落地，其中不乏需要前端同学的付出，还需要领导的支持等等，下面我给大家罗列一下大致的步骤（因团队而异）

1. 要合适的同学（资源）

   • 挨个与前端同学商议，或者自己钦点某位同学等等；而且要有动力，切勿急于求成、半途而废，注重系统思维，也千万不要找不稳定的同学（切记切记切记）

2. 要解决的问题（问题）

   • 针对现有公司前端人员架构、技术架构以及业务架构做对应的方案，这个没有固定的套路，不同公司所面临的问题也不一致；

3. 要解决问题方案计划书（方案）

   • 到目前，咱们已经有人（前端同学），也有具体想要做的事了，那么接下来很重要的一步就是出解决方案找领导确认了；
   • 其实就类似你有一个很好 idea，写了一份特别详细的商业计划书（BP）去找投资人拉投资是一个道理；
   • 不过最后能不能打动你的投资人，这就取决于你的 BP 做的是否够吸引人了；

4. 要具体执行的步骤（执行）

   • 天底下没有一蹴而就的事，工作也是，所以对于一个现有的技术团队，咱们最好是从渐进式出发，在对现有业务不影响的前提下去做增量式的研发；

技术基建四大特性（切记）

• 技术的健全性
• 基建的稳定性
• 研发的效率性
• 业务的体验性

到这里，我相信大家对前端基建已有初步的了解，可能会有同学已经想跃跃欲试了，但是前端基建到底有些什么呢？咱们一起往下看。

四、前端基建都有什么？

前端基建 在每个公司甚者每个业务团队都会有差异，其中有 技术栈的差异，有编码的差异，有文档注释的差异 等等；

为了迎合主要的前端基建市场，结合我司以及大部分公司的基建所需，下面给大家介绍一些符合大众的常用基建部分（后续会持续更新）；

下面所有分类只会简单介绍，详细相关文章会在《前端搞基建》专栏后续发表（敬请期待…）；

1. 前端规范（Standard）

正所谓：前端不规范，后面看着办 ~

我相信规范两个词，是所有同学的噩梦，怕他不规范，又怕他太规范，这可真是难为死这个规范了；

假设招聘现有三个候选人，你会选择哪个呢？

• 一名 “摆烂” 的程序员，写的代码能运行就行；

• 一名 “合格” 的程序员，写的代码能运行且无 BUG；

• 一名 “优秀” 的程序员，写的代码能运行无 BUG 且可读性、可维护性、可复用性都高；

答案显而易见 ~

前端规范的意义：

• 降低开发的成本；
• 保证代码的一致性；
• 提升团队的整体效率；

前端规范有什么？

2.前端文档（Document）

其实在许许多多的小型公司，文档缺失是一项必不可少的问题；无论是 业务文档，还是 技术文档，还是 其它文档等等；

问题点：

• 有些公司招人进来上午安环境，下午直接开始撸需求代码；

• 有些公司的新人来公司一个月了竟然还不知道公司组织架构与业务划分；

• 有些公司老对新几乎无交集，全靠新人猜，一个需求做下来竟然不知道做的什么，只知道一直很忙；

• 有些公司在安排员工去开发另一个项目业务，竟然无从下手，不知所措；

• ……

所以一个合格的公司文档是必不可少的，无论是 新人自治，还是老带新，业务转岗 等等；

前端文档的意义：

• 对新人友好，快速上手；
• 快速融入团队；
• 快速了解业务；

前端文档有什么？

3. 前端项目模板管理（Templates）

前端项目模板 说直白点就是，公司前端所对应的项目模板，以便快速创建项目；

场景一：

前端项目模板主要意义：

• 快速创建项目，提升效率；
• 项目技术栈统一，方便管理；

前端项目模板有什么？

4. 前端脚手架（CLI）

前端脚手架 作为衡量一个成熟前端团队的标准，我相信很多前端er 都对他已经很了解了；

但是目前市面上对脚手架的应用我相信90%以上的团队仅限用于项目的快速创建，也就是使用现成的模板通过命令行快速搭建；

那么我们做这个脚手架是不是已经做到了 资源最大化 呢？

显然是没有的，如何去做我会在后续的文章中详解，大家敬请期待…

场景一：

前端脚手架的意义：

• 快速搭建项目；
• 技术栈统一；
• 规范代码风格；
• 提升研发效率；
• 自动化；

前端脚手架有什么？

5. 前端组件库（UI Design）

前端 UI 组件库：在开源社区有数不胜数的组件库，例如 Ant Design、Element UI、Vant UI 等等（实在太多啦），如果你觉得某个组件库很适合用在你的项目，那么你将少一半的开发时间，是不是摸鱼的时间又多了一半呢？

但是在一些中大型的公司，他们有他们的标准，不可能去使用一些现成的组件库；

而且现成的一些开源组件库中的样式与交互达不到公司设计师的要求，所以这时候 为了统一业务的设计规范与样式，咱们可以马不停蹄地赶紧向领导去提一提搞一个组件库试试看咯！

场景重现：

前端组件库的意义：

• 组件复用，提升研发效率；

前端组件库有什么？

6. 前端响应式设计 or 自适应设计

响应式设计（Responseive Design） 指的是一个网站同一页面在不同屏幕尺寸下有不同的布局；一套代码能在所有终端能够正常展示，并不是为每个终端做一个特定版本，响应式是为解决移动互联网浏览器而诞生的。

自适应设计（Adaptive web design） 需要开发多套界面，通过检测视口以及设备，来判断当前访问的设备是pc端与移动端，从而返回不同的页面。

前端响应式设计：

• 一套代码提升研发效率；
• 不同分辨率设备灵活性强；
• 快速适配多端；

前端自适应设计：

• 设计与体验较好；
• 性能相对好；

注意：

一个项目到底是用响应式设计，还是自适应设计，这个取决于项目的排版和设计的出入程度;

所以如果公司PC端和H5端的排版设计有较大的出入还是建议使用自适应设计；反之可以考虑响应式设计；

切入盲目选择；

7. 前端工具库（类 Hooks / Utils）

开源社区有数不胜数的 前端工具库，如 Day.js、axios、loadsh 等等，只是其中功能未必是你想要的；

而且许多 前端工具库边界考量范围大，这样就增加库的体积，明明我想要的只是一个简单的功能，可还是引入了整个库，这样就得不偿失；

可能有同学要说不是有 Tree Shaking 了吗，难道有了 按需引入 有了 Tree Shaking 我们就可以为所欲为了吗

一些中大型企业团队为了复用某些工具方法，提升研发效率，一般都会封装一个工具库，身为一个合格的基建搬砖工，前端工具库怎么能少得了呢？

前端工具库的意义：

• 工具方法复用，提升研发效率；
• 减少代码量；
• 团队技术提升；

前端工具库有什么？

8. 前端工具自动化（Tools）

可能会有同学疑惑，这个前端工具和上面的前端工具不是一样的吗？

• 前端工具自动化 主要针对的代码上层的格式、规范、测试方面的自动化工具；

• 前端工具库 主要针对的是代码层面的方法复用工具，所以其本质上有较为明显的区别；

场景重现：

前端工具自动化的意义：

• 代码质量与风格的统一；
• 自动化编码流程；
• 提升效率；

前端工具自动化有什么？

9. 接口数据聚合（BFF）

前端 BFF（Backends For Frontends） 即服务于前端的后端，也称聚合层或者中间层；

主要将后端复杂的微服务，聚合成对各种不同用户端（无线/Web/H5/第三方等）友好和统一的API；

场景重现：

前端 BFF 的意义：

• 聚合 API，释放后端；
• 解耦合各个业务；
• 后端微服务引入；
• 易维护和修改 API；
• 更好的安全性；
• 更好的前端错误处理；

前端 BFF 的简单架构：

10. 前端 SSR 推进

服务器端渲染（Server-Side Rendering） 是指由服务端完成页面的 HTML 结构拼接的页面处理技术，发送到浏览器，然后为其绑定状态与事件，成为完全可交互页面的过程。

简单理解就是html是由服务端写出，可以动态改变页面内容，即所谓的动态页面。早年的 php、asp 、jsp 这些 Server Page 都是 SSR 的。

由于公司主要是C端用户，而且 SEO 要求极高，所以在前后端分离的情况下，SSR 就必不可少了 ~

场景一：

前端 SSR 的目的：

• 前后端分离；
• 首屏加载速度快；
• 利于 SEO；

11. 前端自动化构建部署（CI/CD）

前端 CI/CD 一般是指持续集成、部署、发布的一个过程；

用白话文讲，就是你每次 git commit 代码后，都会自动的为你部署项目至 测试环境、预生产环境、生产环境，不用你每次手动的去打包后 cv 到多个服务器和环境；

前端 CI/CD 的意义：

• 提高开发人员生产力；
• 自动化发布；
• 提高代码质量；
• 更快地提供更新；

前端 CI/CD 有什么？

12. 全链路前端监控/数据埋点系统

在大部分 To C 的项目中，我相信产品和运营都需要 统计线上产品在用户中的行为和使用情况，因为这样可以更快的去了解用户群里的使用情况，从而升级和迭代产品，使其更加贴近用户。

场景一：

场景二：

前端监控/数据埋点的目的是：

• 实现精准的点对点营销；
• 可以做相关的分类统计；
• 为用户画像的构建提供数据支持；
• 指导产品研发以及优化用户体验；

前端监控/数据埋点有哪些数据？

• 行为数据：时间、地点、人物、交互、交互的内容；
• 质量数据：浏览器加载情况、错误异常等；
• 环境数据：浏览器相关的元数据以及地理、运营商等；
• 运营数据：PV、UV、转化率、留存率（很直观的数据）；

13. 前端可视化平台

前端可视化 字面意义理解就是用肉眼可见的就称呼为前端可视化；即所见即所得；

笔者这里的理解 前端可视化 包括了 数据可视化、图形可视化、VR 全景可视化、中后台视觉可视化 等等；

其中每一个都需要花费大量的人力与精力，如果你想全方面的从入门到精通，可以看看月影大佬的可视化教程。

目前公司在基于前端基建这块，所做的可视化主要是基于大家的工作流程以及工作效率所做的一个 工程可视化平台；

场景一：

场景二：

前端工程可视化平台的目的：

• 方便项目管理；
• 高效提升工作效率；
• 一键搞定CI/CD流；

前端工程可视化平台有什么？

14. 前端性能优化

性能优化这个词，我相信只要是程序员，多多少少都听过，而且都经历过；

如果你的项目是 ToB 项目，可能性能优化不会做到极致；

但是你的项目是 ToC 项目呢，那性能优化是不是就是一个你必须要考量的点呢？

场景重现：

好家伙，用户直接崩溃，这是什么破网站，这么 🌶 🐔 ；

前端性能优化的意义：

• 页面加载的更快；
• 更好的用户体验；
• 降低服务器负荷；
• 提升编码的能力；

前端性能优化都有什么？

15. 前端低代码平台搭建（建设中）

维基百科定义：低代码开发平台（LCDP） 本身也是一种软件，它为开发者提供了一个创建应用软件的开发环境；与传统编写代码的 IDE 不同，低代码开发平台提供更易用的可视化 IDE。

简单来讲，低代码（Low Code）就是一种可视化搭建系统，从字面意思来讲，一是可视化；二是少写代码。

无代码（No Code） 同样从字面上来理解，一是可视化，二是不写代码。

场景一：

前端低代码平台的意义：

• 降低开发成本；
• 所见即所得；
• 一站式研发；
• 技术收敛；
• 专业门槛低；
• 对新人友好，上手快；

注意：

低代码平台一般较针对于一些业务使用率较大且多是 ToB 的平台，所以判断当前系统是否需要使用低代码平台，建议在有大量业务的支撑前提下，否则得不偿失；

用新技术，更多的不是因为先进，而是适合。

16. 微前端（Micro App）

微前端（Micro-Frontends） 并没有定义框架或 API，它其实是一个类似 微服务架构 的概念；将 微服务 的概念扩展到了前端世界；

说微服务可能有些前端同学会感觉陌生，以咱们前端的角度一句话概括就是： 将您的大型前端应用拆分为多个小型前端应用，这样每个小型前端应用都有自己的仓库，可以专注于单一的某个功能；

需要强调的是，尽管我们将前端应用拆分为多个项目，但它们最终还是会被集成到一个单页前端应用程序中；因此，通过使用微前端架构，您不会在用户体验上有任何损失，只会有过之而无不及；

场景一：

为什么要用微前端：

• 技术上的灵活选择；
• 更快的且独立的部署；
• 团队代码的相互隔离；
• 并行开发和团队的自治；
• 项目的增量升级；

微前端的价值：

如果大家感兴趣可以看看我的《微前端专栏》

总结

关于前端基建，在每个公司基建部分都会有所差异，有纯自动化一条龙的，有半自动化的等等；

但是如果我们细心的会发现，在几乎所有大中厂中，基建部分都不会少了 前端规范、前端文档、前端脚手架、前端组件库、前端工具库，所以如果实在是公司资源与业务限制，这几个还是值得去一探究竟的。

其实很多公司基建都不是一触而蹴的，基本上都是在常年累月的业务当中去 发现问题，定位问题，最后解决问题，然后在这个过程当中自然而然的沉淀出前端各个面向的基础设施，团队成员也会在这个过程当中找到适合自己的前端领域，并且深耕下去。

该系列会是一个持续更新系列，关于 前端基建，笔者主要会从如下图几个方面讲解，如果您想第一时间看到我的更新文章，可以关注我和我的《前端要搞基建》专栏

最后

如果你对 Vite 感兴趣，可以看看我的专栏：《Vite 从入门到精通》

如果你对微前端感兴趣，可以看看我的专栏：《微前端从入门到精通》

如果想跟我一起讨论技术吹水， 欢迎扫一扫加入 前端学习群聊 或加 vx: JeddyGong

感谢大家的支持，码字实在不易，其中如若有错误，望指出，如果您觉得文章不错，记得 点赞关注加收藏 哦 ~

关注我，带您一起搞基建 ~