We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
前端技术飞速发展,各种技术层出不穷,再也不是只会 切图 + jQuery + CSS 就可以行走天下的时代。 随之带来的就是 web 应用的复杂度越来越高,出现问题的概率也越大。
如何解决多人协同高效开发?如何保证项目可维护性?如何高质量交付任务?成为每个前端开发工程师值得思考的一个问题。
为解决上面的问题,大佬们引入了前端工程化这个概念。
将前端开发流程,规范化、标准化、自动化。
项目脚手架可以在新创建一个项目时,简单敲几行命令就可以生成初始化代码,直接进行页面级开发。让开发更加专注于业务逻辑层,而不是各种配置项。
如 vue-cli 脚手架,就可以一键式快速构建 Vue.js 应用开发环境。
Vue.js
我也开发了一个很方便学习的脚手架 feseed-cli,目前支持的模板源码在这里查看。 这样就可以根据公司业务抽离出来一个基础项目模板,当需要启动新项目时,直接敲几行命令就可以啦,提高开发效率,统一了公司前端项目技术栈,开发规范等。
任何重复有规律的编码,都可以用程序方来解决。构建工具大大提高了开发效率,解放了重复劳动力,如:压缩、打包、单元测试等操作,增强了前端开发的可玩性。
构建工具在前端工程化中,像是扮演一个“管理者”的角色。工程化中一系列的规范化、标准化、自动化都需要配合构建工具来实现。
常用的构建工具,如下:
v4.0
CommonJS、AMD、CMD
task runners
require('modules')
ES6 之前没有模块(module)系统,这使得 js 大型应用无法拆分出小的 module,很不方便开发和维护。如:nodejs 中可以使用 require('module')
ES6
module
require('module')
为了解决这个问题,大牛们定制了一些模块化方案,大体可分为以下几种:
在 ES6 内置支持 ESM(ECMAScript Module) 模块系统,有如下特点:
每个人的代码风格都不相同,虽然我们提倡多样性,但是在一个团队中,同个项目有不同代码风格,那便是一种灾难。 不利于项目后期维护,新人熟悉项目成本高
所以,我们需要一起讨论,根据每个人开发习惯,制定统一的代码开发规范
vue
react
在使用 vue-cli 脚手架初始化项目时,会有相关 js 规范配置选择,这里我比较推荐 standard 规范。 因为 standard 规范有比较好的一个特点,无须配置,史上最便捷的统一代码风格的方式。 这样可以为团队节省很多制定规范所浪费的时间,让开发不必纠结于代码规范,把精力放在代码设计、开发上。
vue-cli
当然啦,萝卜白菜各有所爱,还有很多大公司所推出的规范也可以使用,如:Airbnb JavaScript Style Guide、腾讯 Alloyteam 代码规范 等。
为了更具体的展示如何配合 git 钩子,强制规定代码规范,我写了 用 git 钩子, 检测 js 代码规范性(eslint、standard) 文章,具体讲解了,如何在项目中从零配置 js 规范。
我们对特定框架(vue.js)的编码规范也参考了很多规范文章,做了许多讨论。从目录规范到具体开发细节都有了明确规定,具体可看这里
vue.js
Git 是个很好用的代码版本控制工具。在团队协作时,也衍生出一些使用规范,帮助我们提高开发效率、质量。
为什么要保证项目分支图的简洁性?
我们要达到的目标是,任何一个新人,当看到项目提交记录分支图时,就能知道这个项目的迭代大致过程,有助于项目理解和管理。
分支图简洁的重要性,对比如下:
如下图,提交分支图错综复杂,根本看不出有意义的信息
如下图,分支图非常简洁,可读性高,可以清晰的知道代码提交历史,方便回退等操作
如何做到提交信息分支图的简洁性?
branch
git pull --rebase
git push
git push -f
master
commit
tag
hotfix-xxx
为什么要约定统一的提交消息(Commit Message)?
如果每个开发人员都按照自己的意愿去提交消息,那么整个项目的提交历史将会很难分辨提交了哪方面的内容。还有见到提交信息是 123456 !!
所以,我们需要 Commit Message 规范来限制开发人员提交信息的多样性,来提高 Git Commit Message 的可读性。
规范也有很多种,这里比较推荐 conventional-changelog/commitlint 规范,很多知名项目也使用了该规范。
前后端分离式开发已经很常见了,为了提高开发效率,前后端并行开发,mock 数据(造假数据) 已经是个不可避免的问题。 对前端来说 mock 数据的方式有很多种:
mock
Mock.js 模拟数据生成器
GUI
api
easy-mock 是一个可视化,并且能快速生成模拟数据的持久化服务
swagger
Mock.js
RAP 和 RAP2 阿里妈妈出品,开源接口管理工具 RAP 第一代和二代
RAP
JSON
YApi ⭐ 是一个可本地部署的、打通前后端及 QA 的、可视化的接口管理平台
Response
Json5
Mockjs
swagger、postman、json、har
以上,我比较推荐 YApi 平台。
测试种类有很多
对于基础模块,如:常用方法工具库,有必要做单元测试
对于稳定的核心业务,如:支付系统、营销系统有必要做测试
对于非核心业务,功能不稳定的部分,不建议开发自动化测试用例,写测试用例很浪费时间,有时刚写完,需求又变了,还要重新写测试,对人力也是一种浪费。
比较常用的测试工具有:
以前,发布新版本的时候,是用手动发布代码的方式,效率低,出错概率高。
现在,利用 Jenkins 实现自动化构建、测试和部署,大大提高了发布效率,降低了出错率。
错误监控工具,如下:
线上错误监控,是应用发布到线上后很重要的一环,方便预警、统计、追踪、排查、复现 Bug 等。
欢迎关注无广告文章公众号:学前端
The text was updated successfully, but these errors were encountered:
gauseen
No branches or pull requests
背景
前端技术飞速发展,各种技术层出不穷,再也不是只会 切图 + jQuery + CSS 就可以行走天下的时代。
随之带来的就是 web 应用的复杂度越来越高,出现问题的概率也越大。
如何解决多人协同高效开发?如何保证项目可维护性?如何高质量交付任务?成为每个前端开发工程师值得思考的一个问题。
为解决上面的问题,大佬们引入了前端工程化这个概念。
什么是前端工程化
将前端开发流程,规范化、标准化、自动化。
前端工程化
项目脚手架
项目脚手架可以在新创建一个项目时,简单敲几行命令就可以生成初始化代码,直接进行页面级开发。让开发更加专注于业务逻辑层,而不是各种配置项。
如 vue-cli 脚手架,就可以一键式快速构建
Vue.js
应用开发环境。我也开发了一个很方便学习的脚手架 feseed-cli,目前支持的模板源码在这里查看。
这样就可以根据公司业务抽离出来一个基础项目模板,当需要启动新项目时,直接敲几行命令就可以啦,提高开发效率,统一了公司前端项目技术栈,开发规范等。
构建工具
任何重复有规律的编码,都可以用程序方来解决。构建工具大大提高了开发效率,解放了重复劳动力,如:压缩、打包、单元测试等操作,增强了前端开发的可玩性。
构建工具在前端工程化中,像是扮演一个“管理者”的角色。工程化中一系列的规范化、标准化、自动化都需要配合构建工具来实现。
常用的构建工具,如下:
v4.0
支持零配置),常用于 Web 应用开发CommonJS、AMD、CMD
。常用于工具库开发task runners
)的流式(stream)构建系统,与 grunt 功能类似,特点是用流式编写任务代码,gulp 的流实现,每个任务可以并行运行,这使它比 grunt 快很多task runners
)构建工具,grunt 中的每个任务都是一系列不同的插件配置,这些插件以一定顺序一个接一个的执行require('modules')
语法的打包工具,就像在 node 环境引用资源一样JavaScript 模块化
ES6
之前没有模块(module
)系统,这使得 js 大型应用无法拆分出小的module
,很不方便开发和维护。如:nodejs 中可以使用require('module')
为了解决这个问题,大牛们定制了一些模块化方案,大体可分为以下几种:
在
ES6
内置支持 ESM(ECMAScript Module) 模块系统,有如下特点:代码规范
每个人的代码风格都不相同,虽然我们提倡多样性,但是在一个团队中,同个项目有不同代码风格,那便是一种灾难。
不利于项目后期维护,新人熟悉项目成本高
所以,我们需要一起讨论,根据每个人开发习惯,制定统一的代码开发规范
vue
、react
),规定的一些开发规范在使用
vue-cli
脚手架初始化项目时,会有相关 js 规范配置选择,这里我比较推荐 standard 规范。因为 standard 规范有比较好的一个特点,无须配置,史上最便捷的统一代码风格的方式。
这样可以为团队节省很多制定规范所浪费的时间,让开发不必纠结于代码规范,把精力放在代码设计、开发上。
当然啦,萝卜白菜各有所爱,还有很多大公司所推出的规范也可以使用,如:Airbnb JavaScript Style Guide、腾讯 Alloyteam 代码规范 等。
为了更具体的展示如何配合 git 钩子,强制规定代码规范,我写了 用 git 钩子, 检测 js 代码规范性(eslint、standard) 文章,具体讲解了,如何在项目中从零配置 js 规范。
我们对特定框架(
vue.js
)的编码规范也参考了很多规范文章,做了许多讨论。从目录规范到具体开发细节都有了明确规定,具体可看这里版本控制(Git)
Git 是个很好用的代码版本控制工具。在团队协作时,也衍生出一些使用规范,帮助我们提高开发效率、质量。
为什么要保证项目分支图的简洁性?
我们要达到的目标是,任何一个新人,当看到项目提交记录分支图时,就能知道这个项目的迭代大致过程,有助于项目理解和管理。
分支图简洁的重要性,对比如下:
如下图,提交分支图错综复杂,根本看不出有意义的信息
如下图,分支图非常简洁,可读性高,可以清晰的知道代码提交历史,方便回退等操作
如何做到提交信息分支图的简洁性?
branch
,多个开发人可在同一个分支开发,提交前,先用git pull --rebase
,然后再git push
推到远程。解惑 git rebasegit push -f
master
分支,并在最新commit
处,新建tag
,用于标记当前应用版本master
分支,新建hotfix-xxx
分支去处理 Bug为什么要约定统一的提交消息(Commit Message)?
如果每个开发人员都按照自己的意愿去提交消息,那么整个项目的提交历史将会很难分辨提交了哪方面的内容。还有见到提交信息是 123456 !!
所以,我们需要 Commit Message 规范来限制开发人员提交信息的多样性,来提高 Git Commit Message 的可读性。
规范也有很多种,这里比较推荐 conventional-changelog/commitlint 规范,很多知名项目也使用了该规范。
Mock 数据
前后端分离式开发已经很常见了,为了提高开发效率,前后端并行开发,
mock
数据(造假数据) 已经是个不可避免的问题。 对前端来说mock
数据的方式有很多种:Mock.js 模拟数据生成器
mock
数据代码,比较麻烦mock
代码,复用率底GUI
可视化界面,不方便后端开发查看接口、字段等api
信息easy-mock 是一个可视化,并且能快速生成模拟数据的持久化服务
swagger
,可基于swagger
快速创建项目接口Mock.js
语法RAP 和 RAP2 阿里妈妈出品,开源接口管理工具
RAP
第一代和二代Mock.js
语法swagger
数据导入,但支持JSON
格式数据的导入导出YApi ⭐ 是一个可本地部署的、打通前后端及 QA 的、可视化的接口管理平台
Response
断言Json5
和Mockjs
定义接口返回数据的结构和文档swagger、postman、json、har
数据导入以上,我比较推荐 YApi 平台。
测试
测试种类有很多
对于基础模块,如:常用方法工具库,有必要做单元测试
对于稳定的核心业务,如:支付系统、营销系统有必要做测试
对于非核心业务,功能不稳定的部分,不建议开发自动化测试用例,写测试用例很浪费时间,有时刚写完,需求又变了,还要重新写测试,对人力也是一种浪费。
比较常用的测试工具有:
线上部署
以前,发布新版本的时候,是用手动发布代码的方式,效率低,出错概率高。
现在,利用 Jenkins 实现自动化构建、测试和部署,大大提高了发布效率,降低了出错率。
错误监控
错误监控工具,如下:
线上错误监控,是应用发布到线上后很重要的一环,方便预警、统计、追踪、排查、复现 Bug 等。
欢迎关注无广告文章公众号:学前端
参考
The text was updated successfully, but these errors were encountered: