工程化不是简单的使用工具，一切以 降低成本 和 提高效率 或 保障稳定性 做出的措施都应该被归类为工程化的模块中
前言
本文属于《前端工程化系列》的开篇，该系列主要介绍我们一整套前端工程化解决方案。文章会由浅入深的来介绍如何实现前端工程化，以及一整套开箱即用的开源前端工程化解决方案。
文章主要面向中小型团队与新手，希望我们的这一整套工程化之路和解决思路可以帮助团队与开发者提效。
前端工程化
前端工程化主要指从前端项目开始开发到部署线上再到后期迭代维护到这一整个过程，从工程的角度管理前端开发，形成前端开发流程的一整套开发规范或解决方案，提高前端开发效率。
所以我们要想实现前端工程化的根本目的是帮助团队与开发者提升效率和稳定性提升，其本质还是帮助业务取得收益。
研发效能鸿沟
首先团队如果短期面对业务规模扩张的解决办法往往是直接加人，而随着人员规模的提升研发效能却也在不断被团队沟通 & 重复性工作所蚕食，此时继续增加人员规模所能带来的效能提升的收益十分有限。
而随着业务复杂度与人员规模上升所带来的实际研发效能与期待的研发效能的落差就是研发效能鸿沟，工程化是研发效能鸿沟的有效解决方案。
通过工程化可以将团队内可复用的资产沉淀来下避免重复开发浪费时间的同时，工程化所建立的统一规范和标准化流程减少了团队之间的因为沟通和标准产生的效率下降，同时工程化通过提供本地环境与工程化平台可以在研发流程上节省大量时间从而提升效率。
拆解研发流程
要想知道工程化需要在那些方面发力就需要对整体的研发流程有了解。
<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 上的项目建设
总结
工程化的目的是服务团队与开发者，而不是为了实现工程化而工程化，工程化建设的内容，是和业务阶段相匹配的。不同的团队有不同的工程化的需求，同时不同的业务也有不同的诉求。要将团队当前的需求与业务的诉求相匹配借力而行，才能使得团队更长远的发展而不偏离目标。
在不断实现工程化的过程中要跳出工程化的单一视角，跳出前端的身份看到背后所承载的业务的痛点与长期目标。工程化背后的目的是更好的服务业务，将我们通过技术解决的问题更好的赋能帮助业务解决问题。如果你只需要一根针，千万不要去磨铁棒。
