工程化
工程化的概念很广泛，一切提高效率、保障质量的行为都可以归纳到工程化的概念来。
为什么我们需要前端工程化？
前端工程化是指将软件开发中的工程化概念应用到前端开发中，以提高前端开发效率、质量和可维护性的一种方法。前端工程的本质也是一个软件工程，随着软件生命周期迭代以及开发团队的不断更新，大项目的可维护性会越难越差，这主要是一个标准化的问题。自己一个人写的代码要维护起来很容易，但是一个团队中由于每个人的代码风格不一样，需求迭代导致代码耦合、部署冲突等等，导致了项目维护越发困难。因而，我们可以把软件工程化的思想应用到前端开发的各个阶段，用工程化的最佳实践来提高前端开发的质量和效率。
Devops 流程
DevOps（Development and Operations）和软件工程化相似，也是一种软件开发流程和方法，旨在通过自动化、协作和持续交付来缩短软件开发周期，提高软件交付的质量和可靠性。DevOps 流程是指在软件开发和运维中，将开发和运维两个部门紧密结合，彼此协作，共同负责软件的开发、测试、部署和维护的流程和方法。按照前端开发的日常工作流，Devops 流程如下：
而我们的目的就是通过一些自动化工具和流程来实现这个持续集成和交付流程，并保证代码的高质量。
CLI
CLI 是 Command Line Interface 的缩写，即命令行界面。在前端开发中，CLI 是指一些前端工具提供的命令行工具，通过命令行工具可以快速地执行一些常见的操作，例如创建项目、安装依赖、打包代码等。常见的前端工具 CLI 包括 Vue CLI、Create React App、Angular CLI 等。之所以提到 CLI，是因为我们可以借助 CLI 工具来接管代码的打包、构建、部署流程，实现前端工程化，完善 Devops 流程。
既然是按照软件工程的最佳实践，我们可以将前端工程化分为模块化、组件化、规范化、自动化这四个方向进行考量和设计，下一部分的实践也将围绕着这四方面展开。
工程化开发实践CLI 设计需求分析
团队开发可能出现的情形：
项目起步：
加入某个多人开发的项目：
项目开发迭代中出现个性化配置：
功能设计
根据以上功能的划分，我们的 CLI 仓库和模板应该划分为不同的仓库，CLI 提供四大功能的支持，模板提供一套开发的最小套件（根据团队业务和开发习惯决定）。
实践组件化前端组件化
前端组件化是一种将 UI 元素划分为独立的可重用组件的开发方式，组件是一个包含了 HMTL + JS + CSS 的完备单元，在设计时通常基于以下几个原则：
单一职责原则：每个组件应该只关注自己的功能和样式，不涉及其他组件的实现细节。
可重用性：每个组件应该是可重用的，可以在不同的页面或应用中使用。
独立性：每个组件应该是独立的，不依赖其他组件或环境，可以在不同的环境中使用。
可扩展性：每个组件应该是可扩展的，可以通过继承或组合的方式进行扩展，以适应不同的需求和场景。
模板
目前前端组件化框架有很多，主流框架包括基于 JSX 的 React 和基于模板的 Vue 与 Angular，这个可以根据自己的团队需要进行选择。
以 React 为例，一个简单的开发套件如 react-tpl 所示，仅提供了项目开发的入口和产出配置、构建方式、html 模板、基础依赖包等（其中的 script 文件夹做对比用，可忽略），当然，如果团队有需要，还可以再加上路由配置、基础库插入等等。
模块化一切皆为模块
模块化和组件化不同，模块化是针对资源文件而言的，通过模块化技术可以把多个模块的代码按需拼接使用。前端模块化包括 JS 模块化和 CSS 模块化，在现代打包工具如 webpack 的帮助下，不止于此，所有静态资源都是模块，包括图片、音视频、字体等等。
JS 模块化
此处介绍下 JS 模块化帮助理解为什么现在写代码，有的是用 const m = require(“xxx”) ，有的是用 import { m } from “xxx” , 但是却都可以打包运行呢？
JS 历史上一直没有模块化的概念，在模块化概念未出来前，一直是用 IIFE 进行代码隔离。随后在 Node 发布之后，Node.js 使用了 CommonJS 做模块化，但是 CommonJS 只适用于服务端编程却不适合浏览器，再然后又出现了 AMD 和 CMD 两种浏览器端模块化方案，于是人们又推出了 UMD 来统一模块化。而 ES Module 则是 ES 2016 提出的规范，也是目前使用最为广泛的。不同的模块化方案的原理差异很大，依赖解析和执行顺序也不一样，此处就不赘述了。
有了模块化方案之后，我们一般认为一个文件就是一个模块，有自己的作用域，向外暴露特定的变量和函数。目前流行的打包工具有 webpack 和 Vite。在 webpack 中，一切皆为模块，最后文件的打包结果是一个个的 IFEE 函数，这也是为什么可以混用 CommnJS 模块和 ESM 模块的原因。值得一提的是， Vite 在开发模式就是利用浏览器原生支持 ESM 达到快速的项目启动速度和热更新。之前工作时团队主要使用 webpack，本次也以 webpack 打包举例，代码可见于 tiny-cli
托管打包和本地运行
把构建流程统一到脚手架，可以避免业务同学不小心修改了某些配置，导致生产环境问题。
把本地开发运行流程也统一到脚手架，可以避免开发和构建的依赖不同导致构建失败。
把这两个都统一到脚手架中，那我们就可以对打包流程做一些统一的优化啦，比如提取公共模块、压缩图片、产物路径管理等等，这部分在 tiny-cli 中的 build/index.ts 实现。
规范化
前端规范化的内容蛮多的，包括前文提到的组件化中的模板，其实就可以在新建项目时提供了一些目录结构规范。除此之外，作为一个脚手架，还可以统一提供代码风格规范化和 commit 规范化能力。
代码风格规范化
和一般项目配置 eslint 配置文件不同，在脚手架中调用 eslint node api 做代码 lint，同时禁止使用项目本身的 eslint 规则，仅使用脚手架中的配置，代码实现见 eslint/index.ts 。注意，这里只是个简单实现，为了实现流程规范和自动化，还可以再搭配使用 prettier 做代码风格修改，使用 hursky 监听 git hooks, 在 lint-stage 时自动做 eslint。
commit 规范化
约定式提交规范通常要求提交信息包括一个描述性的”类型”、一个可选的”作用域”、一个用于简洁说明的”主题”，以及可选的”正文”和”尾部”等组成部分。同样地，可以用 husky 增加 commit-msg hook软件工程流程，执行 commit 信息校验。
自动化Git Flow 工作流
Git Flow 是一种 Git 工作流，Git Flow是一种 Git 工作流程软件工程流程，是一种基于分支管理的模型，它定义了两个主要分支：master 分支和 develop 分支。master 分支用于存储发布的稳定版本，develop 分支用于存储开发版本；并同时支持性分支，如 feature分支、release 分支和 hotfix 分支等。
在 CLI 中对 Git Flow 可以提供如下的功能：
自动化 CI
我们可在 CLI 中提供：
在自动化这块，受限不同公司的基建差异，此处仅仅提供了一些简单的构想，实际上自动化实现这块需要开发者懂得一些有关运维的知识，包括 docker 和 nignx 等，我也希望能在后续在 tiny-cli 的基础上不断优化加上。
Reference:
———END———
限 时 特 惠：本站每日持续更新海量各大内部创业教程，一年会员只需128元，全站资源免费下载点击查看详情
站 长 微 信：cscs1155
×