前端工程工作流规范

前言

前端开发人员需要了解并熟悉现行前端框架的基础构成，开发规范，工作流及运行方式，才能够更高效、快速的融入到当前开发的工作中来。本文将阐述前端开发过程中需要了解、熟悉并注意的一些方面，包含以下几点

前端架构介绍开发环境和技术栈开发规范流程规范GIT操作规范前端项目介绍

基于工程化、模块化、协作化打造前端框架，我们目标是：打造更好的工程化、模块化、协作化的前端框架

前端架构图

开发环境与技术栈

为保证每个开发人员输出标准化，避免开发时浪费无谓的沟通成本，我们需要开发人员尽量使用统一的开发环境

开发环境

需要在本地开发环境中预先安装以下全局命令

NODE

NODE版本需要安装大于12的稳定版

GIT

需在本地安装大于2.9的版本

VUE-CLI

需在本地安装>=4.0版本

开发工具

VS CODE

为便于文件代码风格统一，建议下载使用 vs code 进行编码工作，我们在项目根目录也配置了 .editorconfig 文件来统一 vs code 编辑器的使用。

ESLINT

代码规范是基于 vue 官方的 eslint 规则eslint-config-vue 进行了配置，vs code 需要安装 eslint 插件。

PRETTIER

建议采用 Vetur 插件来实现代码质量提示&错误、格式化/风格、智能提示格式化。

技术栈

前端项目架构目前基于 vue-admin-template 框架的二次开发版本，需要熟练使用以下相关知识点

VUE

渐进式 JavaScript 框架，Vue.js

VUE-CLI

Vue CLI 是一个基于 Vue.js 进行快速开发的完整系统，介绍 Vue CLI

VUE-ROUTER

Vue Router 是Vue.js官方的路由管理器

VUEX

Vuex 是一个专为 Vue.js 应用程序开发的状态管理模式 开始 Vuex

SASS

成熟、稳定、强大的专业级CSS扩展语言 Sass世界上最成熟、稳定和强大的CSS扩展语言 Sass中文网

ES6

是 JavaScript 的下一个版本标准

ELEMENT-UI

Element，一套为开发者、设计师和产品经理准备的基于 Vue 2.0 的桌面端组件库

开发规范

对于一个开发团队来说，有一套完整的开发规范可以减少团队协作成本和维护成本，可以让代码阅读起来更容易，以下是制定前端协作规范的不同方面的思考，待完善。

代码规范命名规范目录规范

为便于项目代码管理和阅读，统一使用以下目录结构规范，请遵照以下目录规范创建和修改文件进行开发。

├── build                      # 构建相关 
├── public                     # 静态资源 
│   │── favicon.ico            # favicon 图标 
│   └── index.html             # html 模板 
├── src                        # 源代码文件
│   ├── api                    # 所有接口请求 
│   ├── assets                 # 图片、图标、字体等静态资源 
│   ├── components             # 全局公用组件 
│   ├── directive              # 全局指令 
│   ├── filters                # 全局 filter 
│   ├── icons                  # 项目所有 svg icons 
│   ├── layout                 # 全局 layout 
│   ├── router                 # 路由设置 
│   ├── store                  # 全局 store 管理 
│   ├── styles                 # 全局样式 
│   ├── utils                  # 全局公用方法 
│   ├── vendor                 # 公用 vendor 
│   ├── views                  # views 所有页面
│   ├── App.vue                # 应用入口
│   ├── main.js                # 资源载入 应用初始化等 
│   └── permission.js          # 权限管理 
├── .env.xxx                   # 环境变量配置 
├── .eslintrc.js               # eslint 配置项 
├── .babelrc                   # babel-loader 配置 
├── .travis.yml                # 自动化CI配置 
├── vue.config.js              # vue-cli 配置 
├── postcss.config.js          # postcss 配置 
└── package.json               # package.json

环境配置规范

开发分为若干环境，开发人员需要配置相关的配置文件，以配合运维简单使用。请使用上述目录规范中 env.xxx 来进行配置

.env.dev

开发环境

.env.uat

测试环境

.env.pro

生产环境

配置示例

# just a flag
NODE_ENV = development
# env mode
ENV = dev
# base api
VUE_APP_BASE_API = '/dev-api'

流程规范

前端工作开发有一个比较复杂的工作流程，需要与 产品人员、UI、UE、后端、测试，运维等相关人员频繁沟通，优化。导致前端开发工时很容易被动延长。

我们对前端开发工作做分层处理，分为 业务层，公共层，系统层，对应开发人员将分配到 业务组，公共组，系统组中，并开展工作。

下图是一个前端业务正常的流转流程图，主要涉及 公共组，业务组 的开发工作

工作分组业务组

对接人员：后端，测试，产品，运维

工作内容：负责业务推进，分支管理，配合产品优化业务逻辑，配合测试修复逻辑类的bug，并支持运维上线

公共组

对接人员：产品，UI，UE，业务组

工作内容：负责统筹项目样式开发，公共组件开发，形成模块模板页面，文档，DEMO，配合UI/UE优化页面样式，组件交互，配合测试修复样式及组件交互类的bug

系统组

对接人员：公共组，业务组

工作内容：负责维护、升级前端框架，技术选型，多端输出，新技术应用，人员培训，人员招聘

项目推进需求阶段

参与原型评估，理解和明确产品需求，评估开发难度和实现成本，预估上线准备的时间 。

预启动模板构建的相关工作

开发阶段

合理安排项目排期，避免开发过程中发现工作量与预期有严重出入，需要尽早向项目人员反馈，方便修改时间安排。

提测阶段上线

通过提测后，在安排上线前，需要在上线分支添加 tag 标签，便于后续跟踪和代码回滚；

上线后，还需关注功能是否正常运行，各项指标是否正常？比如产品上报数据、性能监控数据、错误监控数据等，是否有可以优化的点。

维护

对于项目上线后出现功能故障点、页面排布展示的问题和性能优化的问题，及时跟进，做好沟通工作，主动推进问题解决。

项目工具

需要关注TAPD项目进度，及时调整工作状态

工作会议

不同组将分别参与不同的会议，能够更高效的开展开发工作

需求评审会

主要由业务组成员参加，参与原型评估，理解和明确产品需求，评估开发难度和实现成本，预估上线准备的时间。

UI/UE评审会

主要由公共组成员参加，及时对不合理的设计需求，或不能及时完成的组件提出明确的信息，促使产品/UI/UE提早修改方案，方便排期工作

周会

全员参与，暴露开发期间遇到的问题，及抛出将要开展的工作内容

Git规范

上线产品是一个严谨的过程，需要在足够复杂的场景中尽可能的暴露出开发中的问题，因此需要部署多个环境以确保上线产品能够完美的呈现给客户，个中依然会有 hotfix 的情况出现，我们需要使用GIT工具一步一步的来推进项目

GIT工作流程图基于分支的GIT工作流

分支名保留分支名

不能使用以下保留分支名，该类分支名统一由运维负责

dev
test
test1
test*
test-1
test-*
uat
uat1
uat*
uat-1
uat-*
master

建议使用的开发分支名称如 dev-name

分支管理

master主分支：
用于生产部署，一般由 uat 分支合并，任何情况下不允许直接在 master 分支上修改代码。
uat分支：
预上线分支，提供生产环境下用户测试验收使用。
dev分支：
开发环境分支，用于开发新需求自测联调使用。
dev-xxx:
以dev-命名开头，用于本地开发使用。

基于标签的GIT工作流

标签命名规范

生产环境： rc-yyyymmdd-序号      （eg：rc-20211027-001）
验收环境： alpha-yyyymmdd-序号   （eg：alpha-20211027-001）
测试环境： test-yyyymmdd-序号    （eg：test-20211027-001）
开发环境： dev-yyyymmdd-序号     （eg：dev-20211027-001）

版本规范

由4位数确定一个版本，如：1.0.0.x，其中 x 作为开发内部使用的迭代版本，前3为由产品定义

COMMIT规范

为了方便项目管理，git commit 信息最好按照一定的格式规范，使用良好的Commit Message有利于代码审查，能更快速查找变更记录。建议规范格式如下：

<类型>(<涉及版本>): <标题>
<空行>
<body>
<空行>
<footer>

常用类型

feat：新曾功能或功能变更
fix：修复bug
docs：文档提交
build：修改项目的的构建工具或外部依赖（webpack、glup等）
style：主要是样式方面的优化、如删除空格、改变缩进、单双引号切换等，并不会影响代码逻辑的修改
refactor：代码重构
revert：回滚某个更早的提交
ci：修改项目的持续集成流程（Kenkins、Travis等）的提交
chore：构建过程或辅助工具的变化
pref：性能、体验相关的提交
test：测试相关的开发

前后端协作规范

真实环境联调。前端将接口请求代理到后端服务，进行联调。