前端工程工作流规范

1,768

前言

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

  1. 前端架构介绍
  2. 开发环境和技术栈
  3. 开发规范
  4. 流程规范
  5. 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 的桌面端组件库 Element - The world's most popular Vue UI framework

开发规范

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

代码规范

  • 统一使用2占位符缩进
  • 统一使用UTF-8字符编码
  • JS使用ES6国际规范撰写
  • JS变量定义使用 CONST 定义,可复写变量使用 let 定义,尽量不用 var 定义
  • JS变量名统一使用小写,常量统一全大写
  • JS复杂变量命名采用驼峰式命名
  • HTML元素嵌套规范,每个块状元素独立一行,内联元素可选
  • CSS样式类名使用 '-' 间隔,如 'A-B-C'
  • CSS样式名统一使用小写
  • CSS统一使用展开格式书写样式
  • 公共方法抽取封装到utils文件目录中
  • 和服务端交互的数据接口尽量在actions中调用,获取的数据通过mutations改变state

命名规范

  • 目录名统一使用小写
  • 复杂目录名使用 '_'下横线 ,如 'A_B_C',不要使用 '-' 中横线
  • 文件名统一使用小写
  • 复杂文件名使用 '_'下横线 ,如 'A_B_C',不要使用 '-' 中横线

目录规范

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

├── 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(测试环境):阶段性开发结束后,推送到此环境由测试人员介入测试
  • UAT环境:相对正式的环境,由内部或者熟人客户介入测试,扩大测试范围
  • MASTER(生产环境):正式面向客户的运维环境
  • DEV-CUSTOM:开发本地环境
  • DEV-STYLE:公共组开发人员的本地环境
  • DEV-COMPONENT:公共组开发人员的本地环境
  • hotfix:需要紧急修复的分支

保留分支名

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

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工作流

前端GIT标签工作流程.jpg

标签命名规范

生产环境: 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:测试相关的开发

前后端协作规范

  • 团队成员遵循规范的协作流程,有利双方开发效率提速,一个典型的前后端协作流程如下:
  • 需求分析。参与者有前后端、测试、以及产品,由产品主持,对需求进行宣贯,确保大家对需求有一致的认知;
  • 前后端开发讨论。讨论应用的一些开发设计,沟通技术点、难点、以及分工问题;
  • 设计接口文档。由后端设计,前端确认是否符合开发要求并进行反馈;
  • 并行开发。前后端并行开发,前端可以先实现静态页面,或者根据接口文档来 Mock 数据进行开发;
  • 联调之前,后端做好接口测试;

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