前言

好久没更文了，由于有许多人问我工程化相关的内容，而我之前的作业中恰好有一些工程化的经历，这儿抽象地和咱们共享一下（无法太详细，详细的话，每部分都需求单开文章长篇大论），所以这儿旨在为咱们树立系统，有需求的话，再渐渐细出吧（比较忙，见谅啦~）

在开端前我问咱们一个问题，前端工程化，是什么？

一提到前端工程化就提到webpack，莫非webpack便是前端工程化吗？webpack是打包东西，啊，前端工程化便是打包啊？

好的，我知道前端工程化了，便是用webpack啦或许用vite打包，然后调一下装备项，该有的都有，打包剖析、treeshaking。。。

诶嘛，我还知道treeshaking呢，加分了！

哈哈哈哈，搞一个小段子~

不知道你有没有上面这样的误区，假如有，我不能说你不对

由于工程化这个东西，它并没有相对一致的规范，每个人或许说是每个公司，每个项目，都去做归于自己的工程化

这是一个探索的进程，并没有对错之分

而在这篇文章，我就说说我对前端工程化的探索、实践，也能够说我的前端工程化是什么样的

咱们假如觉得不对，无可厚非，每个人都有自己的认知和系统，咱们互相学习才是最重要的

我的工程化系统

对我来说什么是工程化

抛去代码，思考一下工程化这个词

我这儿浅浅百度了一下，当然，这几点不一定全面，可是咱们看看，这几个点是不是也贯穿在咱们的代码开发之中呢

那么我觉得，这些点，不论是这上面谈到的，仍是没谈到的，我都想把工程化的概念和用途简略化

赋能

咱们开发一个项目，便是在做一个工程，咱们在开发中探索经历，堆集，形成系统，给团队和接下来的项目赋能，让接下来的作业做的更好，那么我认为这便是在工程化

那么在我的开发进程中，我做过一些我认为是工程化方面的作业，来和咱们共享一下，看看有些东西，咱们是不是觉得耳熟

评定

需求评定，一个在做任何一个项目之前的必备进程

或许咱们做的最多的评定便是功用开发的评定，或许是项目初始开发的评定，咱们会进行评论

一般会有产品、UI、开发、测验，这是最常见的，一般来说便是产品和项目经理起草项目文档，产品和UI完善原型，然后进行功用的评定，评定难度、可行性，从而分出工时，然后在类似禅道的渠道上分发使命和工时，这样就完结了一个基础的初始化系统

有了开端的系统，下面的使命才能更好地进行

规范

好的，咱们现已完结了评定，要开端咱们的项目开发了，假定咱们这是一个新项目，技能栈已定的情况下（在我之前的作业中技能栈一般是主管定），咱们要开端进行项目最开端的建造

项目规范化建造

那这个规范化，咱们一般都说那几个方面呢

• 格局规范化
• 提交规范化
• 命名规范化
• 注释规范化

关于格局和提交规范，咱们除了CR阶段，在日常开发中一般会怎么处理呢

信任咱们看过许多文章了，所以这儿简略带过一下即可

ESlint、 stylelint、prettier来处理一些语言的格局问题

装备husky的pre-commit、增加commitlint装备文件来进行提交的规范化

关于命名的规范化，或许不同的公司的处理方法是不一定的，比方动名词要求，巨细驼峰命名等，一般会写在公司内部的开发文档上

关于开发文档这儿解释一下

开发文档的形式是不固定的，或许是写在语雀、飞书等文档类渠道上，或许是自己经过vuepress或许vitepress自己树立，乃至或许便是写在一个word上，这都是不固定的

开发文档也有多种，咱们不去管那些产品层面的运用文档，就开发层面上来看，我现在触摸的是组件文档和东西文档，前者是内部组件库之类的，后者是内部封装的东西库，这二者往往需求结合文档来进行运用和记载，一起写好文档也便利他人来进行观看和更迭，当然，假如你的目的是防护式编程的话，那随意~可是在我之前的作业中，频频的定时CR事实是不太便利防护式编程

咱们回过头来，除了遵循文档，我经历过哪些命名规范的实践呢，BEM函数是一个

此方法在组件库项目中最为常用，也是开源组件库项目中比较常用的，由于单纯手动遵循BEM规范的话，事实很麻烦，所以咱们借助函数来帮咱们完结，大致是，引入界说块、界说元素

• 根元素用bem()界说块
• 用bem('element')界说子元素
• 多种状态的润饰器用列表bem([])
• 状态为布尔类型的润饰器用目标bem({})
• 一个节点只用一个bem()

详细的实践和介绍能够看这篇BEM 规范及实战快速生成 – (juejin.cn)

而关于注释规范化，其实每个公司的要求是不相同的，比方哪些注释是最终保存的，块级注释的覆盖率的等

由于块级注释能够做到更好的提示功用，并且说白了，看起来就有种规范感，领导是爱看的

一起在开发中，块级注释关于函数、目标、枚举、接口等都是很友爱的

最终，关于规范，其实许多大厂是开源出自己的许多规范的，有许多小公司也都是以大厂的规范为主，大致就像这篇文章的介绍相同

引荐几款代码规范文档库，主张保藏！ – (juejin.cn)

其实还有许多规范，可是我做过的有限，所以不打开说了

东西/自研库/cli/SDK

关于东西/自研库/cli/SDK的开发，是工程化较为直观的表现了

拿上面的规范化举例，假如咱们每开一个项目，都要进行如此繁琐的装备，那么是不是有够头疼，莫非每新来一个同事，都要去手把手去教一下吗，明显不是的，这时分咱们能够封装成一个npm库，一起假如有npm私服的话，能够放到私服上，供内部运用

当然，有钱的或许都去挂CDN了，不同的预算，不同的处理方法

一起，咱们常常会看到一些文章，会觉得pnpm+monorepo好像和前端工程化现已密不可分了，可是自己项目开发中，好像用到的场景的并不多，莫非用pnpm+monorepo只是为了并行发动项目用吗，明显并不是的

在我的作业中，pnpm+monorepo首要用于东西/自研库/cli的开发中，这三者是毫无相干的嘛？并不是的，是密不可分的，monorepo简直替代了lerna进行多包管理，monorepo能够很好地进行拆包而这三者能够经过monorepo很好地串联在一起，形成整理明晰的作业流

咱们这儿拿varlet的拆包举例，由于我觉得varlet在工程化方面做的是很好很明晰的，我也常常来借鉴借鉴大佬们的思路

咱们发现，varlet经过monorepo拆包，形成了十分明晰的作业流，不论是后期的抽离，仍是日常的保护，都是很明晰，舒服的

详细的拆包结构你能够根据自己的项目来定，比方我把一些utils独自拆出来，单测我也独自拆出来，到达我自己的预期需求

cli，也便是咱们常说的脚手架，大部分是用来建造对应的开发模板，中心大致有下面几个阶段

• 指令
  • commander 插件供给指令注册、参数解析、履行回调
• 交互
  • inquirer 插件用于指令行的交互（问答）
• 逻辑处理
  • fs-extra 插件是对 nodejs 文件 Api 的进一步封装，便于运用
  • kolorist 插件用于输出色彩信息进行友爱提示

咱们能够生成咱们想要的模板，有对应的vue、js、ts、md等等，能够生成对应的路由，能够生成对应的单测，只要是咱们想要的，咱们每次都需求重复创立，手动增加的，咱们都能够挑选去搞一个cli来进行主动化处理

然后咱们大致会到达下面的效果

后边我就不展现了，最终根据提示咱们能够主动生成对应的文件模板

yike-design-dev/config/script/new-component.mjs at monorepo-dev ecaps1038/yike-design-dev (github.com)，这儿放上一个示例

一起咱们比较重视的还有SDK的规划，其实咱们或许遇到较多的是前端监控/功用的SDK，原本我想放到后边和监控和优化的时分写的，可是这儿都提到了monorepo，我觉得放在这儿说也无伤大雅

SDK的规划我觉得是很值得学习的，我之前规划的思路是webpack的模式，也便是core配合plugin的方法

这儿其实会引申出十分重要的一点，也便是webpack，有些朋友或许就懵了，什么意思，webpack为什么放到了这儿，不是应该在打包那里吗

这儿就能够纠正一下关于webpack工程化的误区

webpack打包是工程化中打包的一环，而webpack的规划思维是工程化中东西以及SDK开发的一环，而webpack装备和打包剖析以及优化是工程化中优化的一环

并不是说webpack=工程化，可是并不是说webpack≠工程化，准确地说，webpack贯穿工程化，它并不是独自一两个作用那么简略

这也会表现出面试的一些问题，面试想考察webpack，并不是想独自考察你比照webpack的那几个装备，说白了，那几个装备硬记谁记住住，都是去看文档，可是webpack的规划思维和贯穿工程化的这些常识，才是更重要的

比方，在SDK开发中，我尽管用的是webpack的模式，可是我却用rollup打包，是不是蛮有意思的，哈哈哈哈哈

关于SDK的规划，我这儿也有较为引荐的文章

我开源了一款轻量级前端埋点监控sdk – (juejin.cn)

而咱们之前在公司里也是选用的这种模式来进行SDK的开发

然后关于SDK的一些指标咱们下面监控和优化的时分再说

单测

单测即单元测验，其实这个大部分公司內是没有的，由于简直测验作业都会留给专门的测验工程师来做，前端只专心做事务作业

可是这样会有一些问题，比方测验的时刻和开发总是不同步，不知道咱们有没有遇到过，到项目上线的最终的那两天，bug忽然全被指派了出来，然后开端痛苦地加班

一起咱们在进行东西等开发的时分，由于这不归归于事务，所以一般测验工程师是不参加的（当然，假如你们是参加的那更好），并且咱们东西关于代码健壮性的要求是很高的，所以咱们一般会进行前端方面的测验

那咱们一般会进行哪些测验

• 单元测验：测验给定函数、类和复用逻辑
• 组件测验：检测咱们组件的挂载、烘托和交互性
• 端到端的测验：经过真实网络恳求咱们应用并检测夸多页面的功用特性

由于我大部分都是用的vue，所以咱们用的vitest这个框架，信任咱们都有传闻过，相较于之前的Jest装备简略，语法简直相同，文档完善，是个不错的挑选

一起，假如你比较重视开源项目的话，你根本会发现，现在根本上开源项目都会有单测的一环，也是PR的一个硬性要求

一般要求比较高公司或许是开源项目还会对单元测验覆盖率有一定的要求，这个便是见仁见智了

最终，单测并不是一个硬性的要求，它更多的是用于东西开发等，而在事务上较少去用，关于一个大型的事务项目来说，心智担负过大，所以前端单测现在在公司中归于不太垂青的部分（可是我传闻，越来越多的公司开端做前端单测了）

CR

CR，即Code Review（代码检查），我觉得是必不可少的一环，尤其是关于公司新人和实习生来说，它是对代码质量的查验，咱们能够发现自己的代码哪里写的不够好，哪里能够进行改进，这对能力的提高是很有协助的

能够协助自己树立一个良好的代码习气，写出更高雅的代码

不同的公司CR的规范当然是不同的，我拿我经历过的举例

咱们CR间隔是比较长的，一个月一次，由于咱们根本上一个月是一个事务周期，根本上一个月能完结预计的项目开发作业，然后最终打包上线前来进行质量检查

检查的点首要包含上面的代码规范的几点，然后函数的冗繁程度（便是优不高雅），假如vue、react的话会看一些hooks，也便是可复用性强不强，这个进程是互相看的，假如是实习生一般是导师给看，这一般会触及到绩效，和转正之类的，其实是比较重要的

像一些文章会写的，什么规划模式之类的，我觉得一般便是在这儿进行表现，尽管我是不怎么用的，或许我写的就不怎么高雅哈哈哈哈

咱们一般是下午进行CR，时刻是一整个下午左右，根本上时刻只多不少，仍是比较垂青这方面的

打包

其实打包这个咱们比较了解，咱们知道的就有许多，比方vite、webpack等

其实这么说也不对，我觉得也是咱们的一个误区，便是会拿vite和webapck来进行打包东西方面的比较

但事实上vite本质上不是为了打包的，假如真要比较的话也是比较rollup和webpack

由于后两者才是打包东西，来进行代码的压缩、兼并等操作

而vite一般会问一些：为什么vite快啊之类的

也能够问它和webpack的区别，可是拿它和webpack比较我觉得是不稳当的，不知道这也是不是咱们的一个误区

咱们也会发现，现在的许多事务项目仍是选用的webpack来进行打包，由于它对HTML、CSS、以及许多框架较为了解，并且不需求进行单测。

而在咱们上面写的，东西、SDk等开发中，咱们大都都是逻辑，封装，不触及上面的那些，并且会进行单测，这时分会挑选用rollup

然后关于打包的装备项，其实也没什么好说的，许多都是和优化相关的了，除了优化相关的，咱们根本上只重视SourceMap即可

监控

前端监控不知道咱们详细有没有开发过，可是信任咱们大部分是传闻过的

这儿我做过B端和C端的监控，根本上便是过错监控、行为监控和功用监控

过错监控咱们比较容易了解，比方网站哪里出错了，咱们能够经过监控渠道进行上报，定位到哪一行的代码出现了问题（这儿就和上面的SourceMap对应上了），然后一般会调配类似于邮件预警，比方企业微信和飞书等渠道，优势就不用多说了

监控渠道的挑选许多样，例如Sentry,或许Prometheus 调配 Grafana等等，当然，也有许多公司挑选自己开发渠道，都是能够的

只要规划好SDK即可

一起功用和行为咱们需求重视一些指标，然后做出直观的可视化报表等

例如

1. 初次内容制作 (First Contentful Paint，FCP)
2. 最大内容制作 (Largest Contentful Paint，LCP)
3. 初次输入推迟 (First Input Delay ，FID)
4. 交互到制作推迟（Interaction to Next Paint，INP）
5. 累积布局偏移 (Cumulative Layout Shift，CLS)
6. 第一字节时刻 (Time to First Byte，TTFB)

咱们能够经过web-vitals调配Performance API获取规范化的用户体验指标。

还有

• UV拜访数（Unique Visitor）
• PV拜访来量（Page View）
• 记载用户在页面的停留时刻

等等数据需求咱们采集

这个时分SDK显得尤为重要

这就咱们需求重视SDK的接入规划、SDK的运行规划，然后数据上报的时分数据的过滤啊，多端的适配啊，等等

优化

功用优化貌似是前端这两年的热门话题，最简略的，咱们打包的时分能够进行打包剖析，比方webpack-bundle-analyzer，或许你是vite的话就用rollup-plugin-visualizer

然后咱们能够直观地看到各个库的打包体积的占比，然后呢就用CDN什么的优化，之类的

其实许多优化手法咱们都知道，文章也比较多，假如我想详细讲的话，又得开一篇长文，这儿咱们只说一下一个项目，优化的完好流程是什么姿态的

1. 功用指标设定
2. 功用规范确认
3. 收益评价
4. 优化手法
5. 立项
6. 优化实践

当然，也有一些专业的说法，例如RFC，咱们的进程或许有收支，可是又类似

这儿其实我首要想说的是，一个工程化做的好的团队，优化是独自的，很重要的一环，并不是咱们开发中随手优化的

功用优化是需求时刻和成本的，需求多方地评定和收益评价，假如没有实际指标为目的进行盲目优化，是无法得到其它部分和领导的必定的

乃至咱们每个优化的环节都会进行验证、量化、和评价

并且不光是咱们常见的事务场景需求优化，在可视化方面，优化更是让人头疼，比方canvas功用优化，fps掉帧一直是大问题，而webgl更不用说了，比方LOD优化等等，现在也是面试也越老越爱问了

沉积

这儿的沉积不只是说个人的沉积，作为工程化的一环，团队的沉积是很重要的

比方咱们之前会树立自己公司的常识库，比方直接用wolai这种的渠道搭，也能够自己搞一个

然后定时开技能周会，现在有点记不清了，我记住其时是一周一次，然后需求出对应的文章，就类似于现在的技能文章相同，然后放到内部库里边（每篇文章都算绩效，这很重要！）

然后开发出通用性较强的库和东西也算（都算绩效！）

也能够说是技能交流的一种，把自己了解的新技能共享给咱们，由于咱们都了解的话也能更好地进行技能评定，没准下一次就用你引荐的这个库了呢

这种制度会让开发的小伙伴更喜爱去做一些提高本身能力的工作，也更能为团队赋能

结尾

其实工程化真的是一个比较灵活的概念，咱们不要了解的太过死板

只要做的作业对项目、对团队有长久的有益影响，其实都算是工程化

这篇文章旨在给咱们整理一下自己对工程化的误区，给咱们一些方向，并不意在精讲每个环节，由于每环都是很重要和杂乱的，需求独自拿出来讲

我个人了解，工程化有利于提高自己的技能广度，也是成为架构的必修课

当然，这儿我没有写CICD的内容，一是在作业中这不是我由我负责的，我做的都是构建等简略作业，二是由于我觉得运维和布置放在工程化中过于牵强

最终，前端工程化好像现已成为了一种方向，也是面试中较为加分的点，那么重要性就显而易见了，期望这篇文章能协助到咱们

近期都比较忙，只能晚上偶然抽出时刻来写文章，所以简短了些

欢迎咱们进行评论，不明白的能够留言，我会尽量回复的

以及写文章的时分有哪部分我一下子没想起来的，我在后边渐渐补充上去，假如需求每部分独自出文章的，咱们能够说先出哪一块的，渐渐来~

另外，不做收费项目，不接单，不卖课，没那个实力也不想做，单纯共享，所以理性评论蟹蟹~