| 编辑推荐: |
本文
将从前端开发者的角度从开发环境、状态的改变，解决了开发中哪些痛点？以及目前玩物得志前端工程化架构体系的状况一一说明。
本文来自于华为云社区 ,由火龙果软件Alice编辑推荐。 |
|
导读
「前端工程化体系」是一个极度宽广及宏大的概念，以‘软件工程'为例——将工程方法系统化地应用到软件开发中，就叫软件工程；如果说工程是指使用科学原理设计和制造机器、结构等，如修桥、铺路、建隧道、造车、盖房子；那么具体到软件领域，指的是以系统、严谨、可量化的方法开发、运营、维护软件，软件工程包括对这些方法的应用和研究...
工程化的前世今生
纵观前端的发展史，基本经历以下过程
适用小项目，前后端一体，页面基本由JSP、PHP等在服务端生成，浏览器负责展现
B/S 架构兴起，进而有了前端、后端之分；目的降低复杂度，以后端为出发点，有了Web Server层的架构升级，比如Structs、Spring MVC等
- Ajax 带来的数据视图的初步分离，SPA 逐步进入大众视野
随着前端复杂度的上升，模块复用、实践规范越来越重要，在2005年Ajax正式提出，前端开发进入SPA（Single Page Application 单页面应用）时代
但是基于Ajax同样面临着很多挑战：接口约束性、前端开发的复杂度控制。SPA应用大多以功能交互型为主，大量 JS 代码的组织，与 View 层的绑定等，都不是容易的事情。
为了降低前端开发复杂度，Backbone、EmberJS、KnockoutJS、AngularJS、React、Vue等大量前端框架涌现
随着Node.js的兴起，为前端开发带来一种新的开发模式。业界比较出名的实践是，阿里巴巴的中途岛计划。同时利用Node更加便捷管理和简化前端开发过程，前端框架、自动化、构建系统应运而生并发展迅猛
- 基于行业最佳实践，开箱即用的框架（如dva、umi）、工具体系等逐渐建立起来 Node 给前端带来的不光是一种更加便捷的开发模式，更是无限可能
- 前后端职责很清晰
- 业务开发的复杂度可控，通过合理的组件化、模块化、微前端化，让项目持续可维护
- 前端侧部署和服务端解耦，部署更加便捷快速
- 前端可能不再是单一终端开发，面向更广的终端及场景可应用
前端越来越重，复杂度越来越高，配套的前端工程体系也在不断发展和完善，可简单分为开发、构建、发布 3 条主线：
- 前端框架：插件化（jQuery） -> 模块化（RequireJS） -> 组件化（React）
- 构建工具：grunt/gulp（任务化） -> webpack（系统化） -> vite（提速）
- CI/CD：工具化（Jenkins） -> 自动化（Web Hook）
三大主线撑起了前端工程体系，系统地覆盖了前端开发的主流程，其中的工程方法也彼此互补、相互影响，体现在：
- 构建工具让百花齐放的前端框架、类库能够无缝合作
- 前端框架、类库也在一定程度上影响着构建工具（如模块加载、CSS 预处理）、甚至 CI/CD（如 SSR）
工程化主要解决什么
-
规范化 制定各项规范，让工作有章可循；项目初期规范制定的好坏，直接决定后期的开发质量，以及业务迭代代码的腐化速率；规范化主要分为编程规范化、前后端接口规范化、git 分支管理、commit 描述规范...核心要求规则先行，确保项目质量
-
模块化 模块化分为文件级别的以及工程级别，工程的模块化主要是根据工程的业务逻辑和组件特点，将工程拆分成不同的子工程，每个子工程可以单独编译打包发布，降低各自之间的耦合度，比如微前端；文件资源的模块化分为对js脚本的统一整合达到同步加载或者一部加载；CSS 的模块化主要是利用 css modules 对css进行模块化拆分 ， 目前主流的模块化构建工具webpack，避免了重复资源的出现
-
组件化 组件化是指将 UI 页面拆分成“模板+样式+逻辑”组成的功能单元，称为组件(细分领域下可能将业务逻辑解耦，达到纯交互组件)。注意：组件化不等于模块化，模块化是在资源和代码方面对文件的拆分，而组件化是在 UI 层面进行的拆分
-
自动化 自动化是指利用各种持续集成手段，将简单重复的工作交给机器完成，例如自动化测试，自动化部署，自动化构建，持续集成等。目前是市面上主流的工具平台有Jenkins
玩物得志工程化实践
统一前端侧技术栈，针对性提供各场景项目模板，提供组件搭建发布能力，提供终端命令或可视化界面管理的方式创建组件/应用，利用盘古平台可视化执行脚手架构建命令
-
针对不同业务场景提供项目模板
- @wanwu/template-comp-h5-vue H5应用模板
- @wanwu/template-comp-h5-vuets H5基于typescript应用模板
- @wanwu/template-comp-nine-vue 九宫组件模板
- @wanwu/template-utils 工具函数库模板
- ...
- 规范性插件
- @wanwu/eslint-config-app 基于eslint JS编码规范
- @wanwu/stylelint-config-standard 基于stylelint Css编码规范
- commitlint/husky 基于gitHooks 提交注释规范
- 工程管理平台 基于nodeJS和现有的wanwu-cli脚手架能力及盘古流水线创建并关联搭建可视化操作平台女娲
- 各种脚手架 plugin
- cli-plugin-create
- cli-plugin-init
- cli-plugin-doc
- cli-plugin-nine
- cli-plugin-rollup
- cli-plugin-service
- dependency-check-webpack-plugin
- dependency-min-version-webpack-plugin
- router-config-webpack-plugin
- ...
以上即玩物得志工程化实践中所积累的部分模块
wanwu-cli 支持插件式安装的方式，使用者可仅安装自己需要的部分模块
const { runCommand } = require ( '@wanwu/template-utils' );
runCommand( 'wanwu' , [ 'install' , 'create' , 'service' , 'rollup' , 'config' , 'doc' ]); |
便于未来脚手架的拓展能力，插件的快速响应及快速落地，我们将 bin 脚本注入封装，日常需要开发或者拓展脚手架的二级命令仅需改动配置文件即可
// 将脚本注册进行了一层封装
#! /usr/ bin/env node
const utils = require ( '@wanwu/cli-utils' );
const {
commandProxy,
PLUGIN_CALLING_TYPE,
PLUGIN_COMMAD_TYPE,
} = utils;
const { processWanwuPluginCommandConfig } = commandProxy;
const pluginPackageJson = require ( '../package.json' );
const pluginHandle = require ( '../index' );
const pluginCommandConfig = pluginPackageJson.wanwuCmdConfig;
processWanwuPluginCommandConfig({
pluginPackageJson,
pluginCallingType : PLUGIN_CALLING_TYPE.BIN,
pluginCommadType : PLUGIN_COMMAD_TYPE.EXTEND,
pluginCommandConfig,
pluginHandle,
});
// Cmd 配置项
// 将动态读取 package.json 中的配置JSON
"wanwuCmdConfig" : {
"command" : "service" ,
"description" : "玩物service命令行插件，默认自带，不需要安装" ,
"options" : [
[
"-t, --target <target>" ,
"Build target (app | lib | wc , default: app)"
],
[
"-d, --dest <dir>" ,
"output directory (default: dist)"
],
[
"-c --config <config>" ,
"config path (default: ./wanwu.config.js)"
],
[
"--debug" ,
"build in development mode for debugging"
],
[
"-c --env [env]" ,
"build environment setting (default: local)"
]
],
"others" : {
"arguments" : "<type> [entry]"
}
}, |
上面将脚本的实体以及命令的配置项抽离通过形参的方式带入，脚手架的插件开发仅仅需要关注两点：
- 脚本具体需要操作的事情
- 用户在使用脚本需要配置参数及提示
通过脚手架我们可以通过传统命令行的方式初始化项目，运行及构建项目... 但我们仍然觉得不够，利用 nodejs mongoose 等工具搭建可视化的前端工程管理后台 女娲，并衔接目前玩物平台内现有的盘古构建系统，达到一键式建站、一键式创建流水线、操作管理应用或组件等能力
// 后台执行初始化工程命令，在远程仓库中创建工程
async pushProject({
output,
repo,
}) {
await runCommand( 'git' , [ 'init' ], { cwd : output });
await runCommand( 'git' , [ 'remote' , 'add' , 'origin' , repo], { cwd : output });
await runCommand( 'git' , [ 'add' , '.' ], { cwd : output });
await runCommand( 'git' , [ 'commit' , '-m' , '"初始化项目"' , '-n' ], { cwd : output });
await runCommand( 'git' , [ 'push' , '-u' , 'origin' , 'master' ], { cwd : output });
} |
展望未来
以上介绍的都是基于目前前端工程化的一些落地和实现，在实际运用中仍然存在一些问题
- 脚手架的问题 脚手架的本质是复制粘贴一堆样板代码，组成新的项目；造成两个核心问题 ， 第一：创建出来的前端项目因为业务需求需要变动且必须变动，随着一轮轮的重构及贴近业务项目同样会加速分裂和腐化；第二：脚手架本身也会升级迭代，一用即抛，这些改进不能对原先创建的项目带来好处，引入这些改进的成本，跟从其他项目里引入改进的成本差不多
- 项目模板的问题 进一步到项目模板上，脚手架的支撑依赖的就是丰富的项目模块，不但脚手架建设者需要提供多种模板，覆盖不同的需求，使用者也经常需要复制原有模板，修改成新的模板，比如产品的技术形态是 SPA 还是 MPA，都会产生不同的模板，以及需要应对不同的场景类型,这些维度之间的排列组合，要么会导致模板进一步分裂和数量爆炸，每种模板的维护成本更高，应用场景更小，ROI 因此变低，更加倾向于停滞；要么会导致模板对很多维度中的需求，不做考虑，只覆盖小部分需求，对项目开发的支持，局限在比较低的水平。
- 对webpage的包装问题 为了避免每个前端开发者都成为「Webpack 工程师」， 很多脚手架、工程化建设，都会对 Webpack 做封装，在最上层，提供围绕编译构建的两个命令 dev 和 build，搞出不同「规范」的配置文件和插件机制。业务中配置将会越来越繁琐，以及针对不同形态的业务，光有 dev、build 是远远不够的
针对以上出现的问题和趋势背景，前端开发一种新的范式即将到来
- 云工作流
- 由 Web IDE 发展而来的云开发工具，目前正逐渐成为几个大型厂商探索的方向之一。从开发到部署的完整云端工作流方式在未来可能成为标准。
- AI页面自动生成
- 基于 AI 的生成页面工具（例如微软的 Sketch2Code）可以进一步解放生产力。目前，无论是基于设计稿（Sketch/PSD）的精准生成方式，还是基于草图乃至描述语句的 AI 匹配生成方式，仍有各自的局限性。但是随着 AI 技术的发展，这类产品可能会替代目前前端开发过程中的一些基础重复性工作。
以上，我的理解前端工程化是一个系统工程，不同的业务场景及阶段所适合的实践方式不一致。需要通过不断的试错实战积累充足的经验
|
