# 基建系列（一）

# 如何打造属于自己的前端基建

2024/01/23 15:41:20

# 基建的意义

# 为什么要搞基建

在没有基建的情况下，相信大家都会有这样的一些经历：

团队代码风格不统一，团队成员相互觉得代码混乱且难以理解，很难合作；
每次新起项目时度需要再重复一遍之前的所有流程，浪费了大量的时间；而且反反复复的工作让人觉得乏味无趣；
项目越来越大，越来越复杂，没有一套自己的管理方式实在是难以维护，只能是屎山上加屎；
天天写业务代码，毫无长进，渴望搞搞架构成为大佬。

所以这个时候，一套属于自己或者团队的基建就显得格外重要。从起项目到发布，每一步都有自己的技术沉淀，即提升了自己的能力，又把自己从无休止的重新工作中解救出来。

# 基建的优势

编写前端基建的并非单纯地为了追求技术的先进性，而是为了解决项目在发展过程中所面临的一系列共性问题。通过构建一套稳定、可靠的基础设施，开发团队能够更高效地专注于业务逻辑的实现，提高代码的可维护性和可扩展性，实现更高水平的性能和用户体验。

所以一套好的基建模版，应该有以下的一些优势（当然需要视情况而定，不一定要全部达到）：

自动化构建：引入前端基建可以实现自动化的构建流程，包括代码编译、压缩、合并、版本控制等，减轻开发者手动操作的负担，提高项目构建的速度和准确性。
模块化开发：利用前端基建工具，可以实现模块化开发，将大型项目拆分为小的可维护模块，提高代码的复用性和可读性。
代码规范检查：集成代码规范检查工具，确保团队成员遵循一致的编码规范，减少代码质量波动，提高整体代码质量。
自动化测试：引入前端基建可以实现自动化测试，包括单元测试、集成测试和端到端测试，确保代码的稳定性和可靠性。
版本管理：使用前端基建工具可以轻松管理项目的版本，方便回滚、发布和升级，确保团队在不同阶段都能够使用稳定的代码版本。
性能优化：集成性能分析工具，实现自动的性能优化，包括资源压缩、懒加载、缓存等，提高页面加载速度和用户体验。
错误监控与日志：引入前端基建可以集成错误监控和日志记录工具，及时捕获和分析线上错误，提高排错效率。
跨浏览器兼容：利用前端基建工具进行代码打包和转译，确保项目在不同浏览器中的兼容性，提高项目的可用性。
可扩展性：前端基建工具提供了丰富的插件和配置选项，可以根据项目的需求进行定制，保证项目的可扩展性。
团队协作：统一的前端基建工具链能够促进团队协作，减少不同开发者之间的差异，提高整体开发效率。

# 基建的方向和重点

# 方向从何而来

按照我的构想，一个相对完善的研发流程包括以下步骤：

需求录入
需求分析

技术方案确定
任务分解与分配

自动化创建和分配代码仓库与分支权限
本地开发和自测

自动化部署测试环境
测试并修复 bug

提交灰度请求
自动化打包部署灰度

提交生产环境部署请求
自动化部署生产环境

设置监控与报警机制
处理线上问题

数据收集
数据分析

形成最终的需求文档、技术文档和团队文档

根据数据分析和监控结果进行系统和流程的优化

这一套流程强调自动化，强调流程的完整性，我们的基建方向，就应该来源于这些流程中的关键点。举一个例子，上面说的自动化部署，就可以利用 gitlab 的 CI/CD 功能完成自动化部署，通过对分支名字的判断，触发部署不同的环境。

# 重点如何确定

我个人大小公司都待过，个人觉得基建的重点来源于团队的构成。

大厂: 人员充足，流程上应该尽量自动化；业务稳定，那么提高客户满意度应该是首位，那么数据分析也是最为重要的一环；流动性大，那么文档的建设必须非常完善。
小公司: 主要精力在于提高效率完成项目需求，主要工作量都是在代码方面，所以脚手架，组件库等是更好的侧重点。

# 具体搞那些基建

我针对自己搞过的基建以及感兴趣的方向，总结了一下我觉得应该侧重的基建方向

校验规范：eslint、prettier 以及 vscode 的 setting.json(包括本地和工作区) 需要先行，所有人用同一套的规范，需要兼容 window 和 mac 等；
书写规范：各类文件名的命名方式、内部方法和参数的命名方式、接口的发送和请求数据结构等；
提交规范：git 提交的说明需要根据具体的提交填写，比如 feat 开头表示开发新功能，fix 开头带边修复 bug；
分支规范：一定要设置保护分支，防止不熟悉的人乱提交合并，同时给每个人设置具体的权限；无权限者需要提 MR 给有权限者进行代码合并；同时分支命名需要注意，最好加上版本号和开发者名称等可以明显区分的信息；

文档种类太多，列出一些常见的文档如下：

现在前端应用方向有客户端、web 端、小程序等，如 web 端又有 Vue、react、angular 等框架，打包工具又有 vite、webpack 等，再加上一些其他的 npm 包，简单地乘一下这量就上来了。我们哪有那么多精力去学习每一个框架、工具、应用场景的搭建和用法呢，自己搭的话，每个人的理解和配置都不一样，而且费时费力，所以弄一套脚手架工具就至关重要。大家通过这一套脚手架，只需要 1 分钟，几行命令、几个选择就可以搭建好一个项目，而且这些项目的配置如 eslint、prettier、tsconfig.ts、vite.config.ts 等都不需要再额外配置，这脚手架，多是一件美事啊。

一个公司的 UI 风格应该是大差不差的，所以每个项目用同一套组件库完全没毛病。考虑到市面上的组件库如 ant design, element-plus 等都是基础组件，有时候并不能完全满足我们的需求，很多公共的组件都需要重新封装，那就可以搞一套自己的组件库，所有项目都可以共享，避免重复的工作。当然，如果想要开源，那就按照现有的组件库参考自己开发吧，哈哈哈。

每个人都被安装 npm 包时折磨过把，国内使用实在是太慢了太慢了。所以如果你的网络不好或者有限制，搭建自己的镜像库就非常合适。只要设置自动化命令让镜像库每隔一段时间同步一下 npm 源就行了。

写了那么多公共方法，都放到 utils 里面了，结果下一个项目用了一半，那么我就只能调出这一半复制到下一个项目里，累啊。开发一个工具函数库吧，不求一开始就达到 lodash 那种复杂度，慢慢完善，积少成多吗。

手动部署存在很多潜在问题，包括复制粘贴、手动配置文件、潜在的人为错误等，这不仅浪费时间，也增加了出错的概率。因此，自动化部署成为解决这一问题的重要方式。在这一过程中，使用 CI/CD 工具（如 GitLab CI）可以极大提高效率。通过配置简单而强大的 gitlab-ci.yml 文件，我们可以实现提交代码后的自动构建、测试和部署。这个过程不仅可以根据分支名字区分不同环境，还能够通过设置参数执行一些特殊操作，使整个部署过程更加灵活。这种自动化部署的好处不仅在于提高了部署速度，还在于降低了人为出错的可能性。即使是新成员加入，只需了解一下 CI/CD 的配置文件，就能够轻松理解和参与到自动化部署流程中。这样团队可以更专注于开发和创新，而不是花费大量时间在手动部署和错误排查上。

数据埋点是通过在应用程序代码中插入代码片段，跟踪用户在应用内的操作。这些操作可以包括页面浏览、按钮点击、表单提交等。数据埋点的目的是收集丰富的用户行为数据，为后续分析提供基础。收集到的数据通过分析工具进行处理和解读。这些工具能够帮助我们了解用户的习惯、喜好以及在应用中的痛点。通过分析数据，我们可以发现用户的转化路径、瓶颈所在，并作出相应的优化措施。下面是一些数据类型：

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

微前端的初衷是为了解决老旧项目难以维护，技术落后的问题，而现在也扩展到由小项目聚合成大项目，每个小项目专注于单一的功能，解决各个团队技术栈不一致、各个团队沟通成本等问题。微前端目前比较流行的框架如下，这也是我用过的几个微前端框架：

qiankun: 基于 single-spa ，阿里系开源的微前端框架，应该也是大家接触最多的了，社区比较活跃，这点比较重要。
Micro-App：Micro App 是京东出的一款基于 Web Component 原生组件进行渲染的微前端框架，不同于目前流行的开源框架，它从组件化的思维实现微前端，旨在降低上手难度、提升工作效率
无界：无界是腾讯推出的一款微前端解决方式。它是一种基于 Web Components + iframe 的全新微前端方案，继承 iframe 的优点，补足 iframe 的缺点，让 iframe 焕发新生。

Monorepo 是指在单一版本控制仓库中管理多个项目的软件开发模型。优势在于能够更容易共享代码、依赖管理、版本控制和跨项目的协同开发 pnpm 使用一种称为“逻辑链接”的方法，将依赖项链接到项目中，而不是将它们复制到每个项目中。这种链接的方式能够在系统中共享依赖项，从而减少磁盘空间的使用，并提供更快的安装和运行时。

遇到巨石项目或者多项目相互依赖的情况怎么办，总不能改造成微前端吧，这也太浪费了，要知道，微前端的通信是很复杂的，而且微前端主要还是解决技术栈和团队协作问题啦。所以这个时候，monorepo 模式就非常契合了，他的单仓多包模式就能够完美解决这个问题。再搭配上以及支持 monorepo 的 pnpm，完美解决项目分割和项目互相依赖引用的问题。

常见的使用这种模式的项目场景如下：

前端框架Vue
原子化样式方案UnoCss
UI 组件库，如 Element-plus
设置多端的 web 项目

# 说在最后

搞基建是一个很麻烦很复杂也很累的事情，但是呢也是实现自己的额外价值（可以理解为卷绩效），提升自己能力和竞争力的一种方式，甚至也是偷懒的一种方式（毕竟从重复的工作中解放了出来），所以呢，有空的话搞一搞还是很有必要的。基建有时候会涉及不属于自己领域的知识，很多人会在经历挫折后就放弃，但是我想说的是，搞基建是一个循序渐进的过程。不求一开始就完美，一点点来，一点点完善即可，那个主流技术没有迭代几十个版本的对不对，所以坚持吧，坚持地搞下去，才能有自己的技术沉淀啊，我之前经常性地被一个问题搞一两天，甚至好几天呢，所以遇到问题安啦。