前端工程（一）开篇

如上图所示，可以看到前端研发流程的整体环节。在这个环节中，中小前端团队或开发者普遍缺乏工程的麻烦环节往往在“开发准备阶段”、“编码&连接调试阶段”和“调试优化阶段”。其中，“开发准备阶段”缺乏系统规范，往往导致团队中不同开发人员的代码风格不同，代码实现层次不一导致后期迭代维护成本高。在“coding&联调阶段”，往往会出现组件、工具功能等基础设施缺失等问题，以及前后端进度不一导致的前端等接口等项目节奏问题。团队后端，后端接口质量差。在整个研发流程周期中，这两个阶段往往消耗的时间最多，所以前端工程在这两个环节的作用就是帮助开发者更顺利、更快速地完成开发。所以我们需要梳理R&D在没有工程化的过程中会遇到哪些问题。缺乏工程化带来的问题缺乏团队规范和制度个人风格的代码大大增加了维护成本缺乏统一的标准和最佳实践Commit不明确，给紧急修复带来额外的麻烦新项目需要大量时间来完成各个项目准备工作配置缺少快速启动的cli。大量重复的组件被复制粘贴到各个项目中。使用未解决的工具库和钩子库。常用的函数和代码分散在各个项目中。《各自实现》复制粘贴代替团队沉淀优质方案接口mocks依赖前端本地手写模拟，或者等待后端接口大量接口请求代码不断复制，临时功能满满开发者插入的项目没有监控，前端对在线问题没有感知。缺席使得前端对业务的认知上线。很多UI开发占用了研发时间，没必要从业务上做更高的改进。急需“低代码”工具帮助团队解决大量重复性低价值的后台UI开发。工作团队不知道如何切入BFF等服务端场景，所有环境服务端功能都依赖于后端实现。随着前端研发过程的一个接一个的展开，我们解构了一个项目在开发过程中遇到的各种问题的复杂性。从上图可以看出，前端业务研发中遇到的大部分问题，都被拆解成了两部分。左边是可避免的软件开发复杂度，右边是胶水代码和业务逻辑。Avoidablesoftwaredevelopmentcomplexity：这里是我们按业务划分的软件开发的基本成本，比如一些基础组件，业务组件，以及工具库等可复用资产。这里的开发成本往往可以积累一次，在团队中重复使用，大大提高效率。工程这里能做的就是把它拆解成可重用的基础组件、业务组件、hooks和utils，以及cli和template。通过积累可复用资产，避免重复开发，提高研发效率，完成工程化。第一步。同时，需要制定团队系统规范，完善代码风格的约束和代码实现的质量，避免业务发展带来的额外维护成本。胶水代码，业务的最后一公里：业务方面，我们在实际业务开发过程中遇到了一些问题，比如数据源（接口）的Mock需要手写，后端同学IDL，缺少监控数据等工程在这里可以做的是提供一个统一的Mocks平台，根据文档生成服务层代码，Mocks的能力，为团队提供前端嵌入和监控解决方案，解放繁重但低价值的UI开发工作量低代码构建平台。工程化设计同时，我们需要的不仅是面对新业务效率的提升，还要在工程化的过程中帮助老业务提升效率。也就是说，我们不能因为工程的原因，对老项目进行大量的追加改动，也不能完全忽视老项目提高效率的需求。这就需要我们设计一个工程架构，能够尽可能少的对业务进行侵入，同时尽可能多的进行改动。可以帮助更多的企业。根据以上拆解问题，绘制出解决研发阶段工程问题的架构设计图。我们将按照该架构一一解决工程化缺失带来的问题，通过基础设施和工程化的不断完善来提高效率和保证稳定性。性目的。通过以上工程需求分析和工程架构设计，我们针对这些具体目标有如下设计，流程完全具备后可以进一步升级为平台+产品化。可复用资产：CLI、Template、Components、Hooks、Utils等团队可复用基础设施基础设施：提供统一Mocks服务的OneAPI平台监控埋点：一键获取全埋点监控Eagle-Eye搭建服务：中后台乐高搭建platform和Formilyform构建平台打包构建：基于团队现有构建服务和one-publish发布平台发布灰度：基于统一项目发布平台实现灰度&回滚我们会在后续这篇文章中介绍并实现上面列出的功能将我们已经实践过的项目一一进行工程化，并将已经实践过的项目开源，让开发者通过简单的修改就可以获得完全符合自己需求的工程化产品。创建一个平台，将这整套前端工程成果和流程串联起来，形成工程平台的产品D-One。我们将D-One定义为前端工程的“一套”，以low-code为核心的一整套前端工程解决方案。目的是打造一个功能完备的平台，可以帮助开发者完成模板选择、初始化、监控、嵌入、apimocks、请求接口代码生成、低代码构建、构建、发布。温馨提示：D-One是我们建立的一套前端工程应用平台。目的是解决从新建项目到发布的全流程平台。它仍在不断建设中。有兴趣的可以参与Github上的项目建设总的来说，工程的目的是为团队和开发者服务，而不是为了工程而工程。工程建设内容与业务阶段相匹配。不同的团队有不同的工程需求，不同的业务也有不同的需求。只有将团队当前的需求与业务的需求相匹配，团队才能在不偏离目标的情况下长期发展。在持续工程的过程中，需要跳出工程的单一视角，跳出前端的身份，看到背后业务的痛点和长远目标。工程背后的目的是为了更好地服务于业务，更好地赋能我们通过技术解决的问题来帮助业务解决问题。如果您只需要一根针，切勿削尖铁棒。前端基础设施建设参考文档|堂主-如何推进前端团队的基础设施建设