前端工程化

写代码真的好开心啊

已于 2023-06-18 11:26:54 修改

阅读量89

点赞数

文章标签：前端 javascript css

于 2023-06-17 21:15:26 首次发布

本文链接：https://blog.csdn.net/w499198977/article/details/131257709

版权

什么是工程化

前端工程化是指遵循一定的流程和规范，通过工具去提高效率，降低成本的一个手段。

日常开放中可能会面临的问题

想要使用 ES6+ 新特性，但是兼容有问题
想要使用 Less / Sass / PostCSS 增强 CSS 的编程性，但是运行环境不能直接支持
想要使用模块化的方式提高项目的可维护性，但运行环境不能直接支持
部署上线前需要手动压缩代码及资源文件，部署过程需要手动上传代码到服务器
多人协作开发，无法硬性统一大家的代码风格，从仓库中拉回来的代码质量无法保证
部分功能开发时需要等待后端服务接口提前完成

工程化主要解决的上述问题所代表的情况，主要为：

传统语言或语法的弊端
无法使用模块化/组件化
重复的机械工作
代码风格统一、质量保证
依赖后端服务接口支持
整体依赖后端项目

工程化的体现

一切以提高效率、降低成本、质量保证为目的的手段都属于工程化

比如，在创建项目的过程中使用脚手架工具来完成项目基础结构的搭建，技术选型这些；开发时统一规范（代码规范、git规范、项目规范、UI规范），自动格式化代码，自动校验代码风格这些；预览环节可以使用mock数据，热更新这些；在提交环节用 git hook 自动化在代码提交之前做项目检查（质量检查，代码风格检查，git log 格式限制等）

技术选型

简单来说，三个框架选一个。可以按照以下特点来选择：

选你或团队最熟的，保证遇到棘手问题时有人能填坑
选市场占有率高的。

以下是个人私货，仅供参考：

如果对上述两条不是很苛求，那么，如果你的项目是一个对复杂性UI 需求更大的项目的话，我建议选 react 。相对于 VUE 的模板语法，JSX 应对复杂性UI 的场景会更舒服，本身 JSX 就更灵活，用 VUE 来应对这样的场景的话就会出现大量的 slot，写的时候一时爽，看的时候火葬场，对于新加入的员工更是如此。

反之，如果项目是个常规性UI 或者用户会有大量 I/O 的项目的话，那就选择 VUE。VUE 的双向数据绑定比 react 的手动绑定（说的就是你 setState）要舒服太多了，不然的话就会遇到写 setState 写到想吐的情形。

至于 Angular，我只能说，个人可以学一下，写几个 DEMO 玩玩就好了，招不招到人那就是看天意。。。

统一规范

代码规范

统一代码规范的好处有以下几点：

规范的代码可以促进团队合作
规范的代码可以降低维护成本
规范的代码有助于 code review（代码审查）
养成代码规范的习惯，有助于程序员自身的成长

如何制定好的代码规范

找一份基础的代码规范，在此基础上根据团队的需求进行客制。github 上一些比较高星的规范有 Airbnb，standard 等等。CSS的规范有 styleguide 等。通过 eslint + stylelint + vscode 来检查代码规范。

git规范

git规范分分支管理规范和 git commit 规范，分两头说

分支管理规范

git 提供多种分支管理策略，可以根据不同的开发场景创建和合并不同的分支，如feature分支、release分支、hotfix分支等。一般情况下分主分支（master）、开发分支（develop）其他分支。成员想要开发新功能或者修改BUG时，就从 develop 开一个新分支进行开发，等开发测试都完成后，就合并进 develop，再合并进master分支。这时候有人会说，这 master 分支的作用不是跟 develop 分支的作用一样了吗？其实不然。在我看来，master 永远只存放你们需要发布的最高版本的代码，而 develop 则可以存放你们开发的最高版本。比如说，你们项目的当前版本是V1.1，那master就是存放V1.1的代码，而你们开发到V1.6甚至V2.0的代码则放在 develop，这样对于项目的线上版本的控制会比较方便。但这也只是我的一家之言，如果你们觉得你们的版本控制的方法更适合你们公司，那就用你们自己的方式。

commit规范

一句话概括，<type>[number](content)

type：此次提交的类型

feat: 新功能、新特性
fix: 修改 bug
perf: 更改代码，以提高性能
refactor: 代码重构（重构，在不影响代码内部行为、功能下的代码修改）
docs: 文档修改
style: 代码格式修改, 注意不是 css 修改（例如分号修改）
test: 测试用例新增、修改
build: 影响项目构建或依赖项修改
revert: 恢复上一次提交
ci: 持续集成相关文件修改
chore: 其他修改（不在上述类型中的修改）
release: 发布新版本
workflow: 工作流相关文件修改

number：对应的 bug 编号或者需求编号，也可以直接贴链接

content：对于此次提交的主题描述

举个例子

<feat>[114514]新增用户管理功能

项目规范

主要是项目文件的组织方式和命名方式。

/**
以vue举例

    |-public(公共资源，不会被 webpack 处理)
    |-src(源码)
        |-api(接口)
        |-assets(静态资源)
        |-components(公共组件)
        |-styles(公共样式)
        |-router(路由)
        |-utils(工具函数)
        |-views(页面)
    |-test(测试代码)

*/