关于javascript:前端工程化一开篇

工程化不是简略的应用工具，所有以 降低成本 和 提高效率 或 保障稳定性 做出的措施都应该被归类为工程化的模块中

前言

本文属于《前端工程化系列》的开篇，该系列次要介绍咱们一整套前端工程化解决方案。文章会由浅入深的来介绍如何实现前端工程化，以及 一整套开箱即用的开源前端工程化解决方案。

文章次要面向 中小型团队与老手，心愿咱们的这一整套工程化之路和解决思路能够帮忙团队与开发者提效。

前端工程化

前端工程化次要指从前端我的项目开始开发到部署线上再到前期迭代保护到这一整个过程，从工程的角度治理前端开发，造成前端开发流程的一整套开发标准或解决方案，进步前端开发效率。

所以咱们要想 实现前端工程化的基本目标是帮忙团队与开发者晋升效率和稳定性晋升，其本质还是帮忙业务获得收益。

研发效力鸿沟

首先团队如果短期面对业务规模扩张的解决办法往往是间接加人，而随着人员规模的晋升研发效力却也在一直被团队沟通 & 重复性工作所鲸吞，此时持续减少人员规模所能带来的效力晋升的收益非常无限。

而 随着业务复杂度与人员规模回升所带来的理论研发效力与期待的研发效力的落差就是研发效力鸿沟 ， 工程化是研发效力鸿沟的无效解决方案。

通过工程化能够将团队内可复用的资产积淀来下防止反复开发浪费时间的同时，工程化所建设的对立标准和标准化流程缩小了团队之间的因为沟通和规范产生的效率降落，同时工程化通过提供本地环境与工程化平台能够在研发流程上节俭大量工夫从而晋升效率。

拆解研发流程

要想晓得工程化须要在那些方面发力就须要对整体的研发流程有理解。

<div align=center>@堂主 制作的前端研发流程图 </div>

如上图所示能够看到前端研发流程的整体链路，在此链路中个别中小前端团队或开发者因 工程化缺失带来困扰 的环节往往在「 开发筹备阶段 」与「 编码 & 联调试阶段 」和「 调试优化阶段」。

其中「开发筹备阶段」制度标准的缺失往往带来团队中不同开发者的代码格调迥异，代码实现水准不一造成前期迭代保护的老本很高。

而「编码 & 联调阶段」往往会呈现像组件、工具函数等基建缺失，以及团队中前后端进度不一带来的前端等接口、后端提供接口品质差等我的项目节奏的困扰。

在整个研发流程周期中往往也是这两个阶段所耗费的工夫是最多的，那么在这两个环节中前端工程化的作用就是帮忙开发者更顺畅更疾速的实现开发。

所以咱们须要整顿出在 没有工程化的时候研发在流程中会遇到什么问题。

工程化的缺失所带来的问题

• 短少团队标准与制度

  • 个人风格的代码使得保护老本大大晋升
  • 短少统一标准与最佳实际
  • commit 不清晰，对紧急修复产生额定困扰

• 新我的项目须要占用不少工夫实现各项筹备工作配置

  • 短少 cli 来进行疾速启动

• 大量反复的组件是在各个我的项目中复制粘贴应用

  • 没有积淀的工具库、hooks 库
  • 高频应用的函数与代码扩散在各个我的项目中「各自实现」
  • 复制粘贴取代了团队积淀的优质解决方案

• 接口 mocks 依赖前端本地手写模仿，或期待后端接口

  • 大量接口申请代码一直 copy，充斥着开发者塞入的长期性能

• 我的项目无监控，前端对线上问题无感知

  • 埋点、监控的缺失使得前端对业务上线之后的感知变弱

• 大量 UI 开发占用研发工夫，没有从业务中取得更高的晋升

  • 急需「低代码」工具能够帮忙团队解决大量反复低价值的后盾 UI 开发工作
• 团队不晓得如何切入 BFF 等服务端场景，所有环境服务端大小性能都依赖后端实现

随着逐个拆前端研发流程上开发环节的问题，咱们解构了一个我的项目在开发过程中所遇各个问题的复杂度。

从上图咱们能够看进去绝大部分前端业务的研发上遇到的问题被拆解成两局部，右边是可防止的软件开发复杂度，左边则是胶水代码与业务逻辑。

可防止的软件开发复杂度：

这里是咱们依据业务划分的软件开发的根底老本，例如一些根底组件、业务组件和工具库等可复用的资产。这里的开发成本往往能够通过一次实现积淀下来在团队中一直的复用来大幅度晋升效率。

工程化在这里能够做的就是拆解成为 团队可复用的根底组件、业务组件、hooks 与 utils、以及 cli 和 template，通过积淀可复用的资产达到防止反复开发，晋升研发效率实现工程化的第一步。同时须要制订团队的制度标准，欠缺代码格调的束缚与代码实现的品质，防止随着业务倒退而产生额定的保护老本。

胶水代码、业务最初一公里：

业务上咱们依据理论业务开发的过程中遇到的一些问题，例如数据源（接口）的 Mock 须要手写、后端同学 IDL、监控数据缺失等等。

工程化在这里能够做的就是提供 对立的 Mocks 平台、依据文档生成 services 层代码、以及 Mocks 的能力，提供团队前端埋点、监控计划，通过低代码搭建平台解放沉重但低价值 UI 开发工作量。

工程化设计

同时咱们须要的是在工程化的过程中不仅要面对新业务无效能的晋升，同时也要帮忙老的业务晋升效力。即不能因为工程化而对老我的项目产生大量额定的改变，也不能齐全不思考老我的项目提效的需要，这就要求咱们须要设计一套能够尽量少侵入业务的工程化架构的同时也尽可能的能够帮忙更多的业务。

依据下面拆解的问题画出了用于解决研发阶段的工程化问题的架构设计图，咱们将依据该架构逐个解决工程化缺失带来的问题，通过不断完善基建与工程化达到晋升效率保障稳定性的目标。

通过上面对工程化需要问题的剖析和工程化架构的设计，咱们针对这些具体的指标有如下设计，并在该流程的能力齐备后能够进一步晋升到平台化 + 产品化。

• 复用资产：CLI、Template、Components、Hooks、Utils 等团队可复用基建
• 基础设施：提供对立 Mocks 服务的 OneAPI 平台
• 监控埋点：一键式接入的全埋点监控 Eagle-Eye
• 搭建服务：中后盾 Legao 搭建平台和 Formily 的表单搭建平台
• 打包构建：基于团队以后已有的构建服务和 one-publish 的公布平台
• 公布灰度：基于对立的我的项目公布平台实现的灰度 & 回滚

咱们会在后续的文章中逐个来介绍和实现上述工程化列出的性能以及开源咱们曾经通过实际的我的项目，让开发者能够通过简略的批改就能取得齐全匹配本人需要的工程化产物。

打造平台

把这一整套前端工程化的成绩与流程串联起来就造成了工程化平台的产品 D-One。咱们将 D-One 定义为一个前端工程化的「集」，是 以低代码为外围的一整套前端工程化解决方案。目标是想打造一个能够帮忙开发者实现 模版抉择、初始化、监控、埋点、api Mocks、申请接口代码生成、低代码搭建、构建、公布这样一个功能完善的平台。

舒适提醒：D-One 是咱们建设的一整套前端工程化利用的平台，目标是解决我的项目从新建到公布的全流程平台，目前还处于继续的建设中，感兴趣能够一起参加 Github 上的我的项目建设

总结

工程化的目标是服务团队与开发者，而不是为了实现工程化而工程化，工程化建设的内容，是和业务阶段相匹配的。不同的团队有不同的工程化的需要，同时不同的业务也有不同的诉求。要将团队以后的需要与业务的诉求相匹配借力而行，能力使得团队更久远的倒退而不偏离指标。

在一直实现工程化的过程中要跳出工程化的繁多视角，跳出前端的身份看到背地所承载的业务的痛点与长期指标。工程化背地的目标是更好的服务业务，将咱们通过技术解决的问题更好的赋能帮忙业务解决问题。如果你只须要一根针，千万不要去磨铁棒。

参考文档

前端搞基建 | 堂主 – 如何推动前端团队的基础设施建设