关于前端:前端规范落地团队级的解决方案

本文次要讲前端开发时遇到的 编码标准难以落地的问题 以及 解决方案 ，包含 编码标准 和 git commit 标准。

重点在 落实前端团队编码标准 的操作上。跟着我一步一步去做，肯定能够将标准落地。

问：要不要制订编码标准？要不要应用 ESLint？要不要规范化 git 的提交？

答：非集体我的项目 我都倡议遵循团队或支流的标准进行编码。写代码和浏览代码是两回事，团队单干的话，代码最好都能让每个成员看着感觉难受。git 的日志也同样是这个情理，写和读是两回事。

团队开发的我的项目如果没有开发标准：

日后保护老本大概率会变高。
可能看不懂共事的代码（共事也不肯定能看懂你的代码）。
我的项目不容易扩大。
公司人员流动时，我的项目难以交接。
丑！

比方这样的代码就十分丑

const userInfo ={
  name: "张三",
  age:20,
  gender: '男'
}

function showUserInfo() {console.log('姓名：'+userInfo.name)
console.log("年龄：" + userInfo.age);
console.log("性别：" +userInfo.gender);
}

showUserInfo()

有些中央应用单引号，有些中央应用双引号。
userInfo ={...} 等号前面没空格。
age:20 冒号前面没空格。
showUserInfo 里的代码有两行没用制表符排版。
有些代码有加分号，有些代码没加分号。
字符串拼接时，局部加号两边没空格。

尽管这段代码是能运行的，但看上去就十分丑。甚至在很多公司中，这种代码都是不合格的，大概率会公开处刑。

至于应用什么标准（比方要不要加分号），本文不做深入探讨。
你能够依照团队协商进去的标准去编码，也能够应用大厂提供的标准。

🎗️文末放了几份大厂标准的链接~

有标准是坏事，但也因而引发一些问题：

团队成员能力参差不齐，依照高标标准局部成员会被迫 升高开发效率。
新成员退出，难道要残缺看一遍标准文档？看完也不肯定记得住。

针对上述问题，当初比拟风行的 解决方案是：自动化！

保留代码时：主动格式化代码，之后再检测编码是否合乎团队标准，不合规的提醒谬误。
提交代码时：检测编码是否合乎团队标准，不合规不容许提交。
编写 commit message 时：提供日志模板。

也就是说

用 ESLint 查看编码标准；
用 Prettier 插件主动保留为布局化格局；
用 Commitizen 约定提交标准；

本文案例运行环境和编辑器

node ^16.13.1

npm ^8.1.2

@vue/cli ^4.5.15

应用了 VS Code 编辑器

我会用 vue-cli 创立一个 Vue 我的项目做示范，React 我的项目的做法其实也差不多的。
接下来的代码、语法根本不会依赖 vue，因为本文是讲代码标准和 Git 提交标准。

没装置 vue-cli 的同学能够应用这条命令装置一下。

npm install -g @vue/cli

而后应用 vue-cli 创立我的项目。

#【第 1 步】应用命令创立我的项目
vue create 我的项目名（小写英文）######################################################

#【第 2 步】抉择模板
? Please pick a preset: Manually select features
Vue CLI v4.5.15
? Please pick a preset: (Use arrow keys)
  Default ([Vue 2] babel, eslint)
  Default (Vue 3) ([Vue 3] babel, eslint)
> Manually select features  # 抉择这项，手动匹配

######################################################

#【第 3 步】抉择须要的性能。请依据本人的项目选择，本文只做代码标准，所以 vuex、路由、css 预处理器这些我都没选。? Check the features needed for your project: (Press <space> to select, <a> to toggle all, <i> to invert selection)
 (*) Choose Vue version
 (*) Babel
 ( ) TypeScript
 () Progressive Web App (PWA) Support
 ( ) Router
 ( ) Vuex
 ( ) CSS Pre-processors
>(*) Linter / Formatter  # 代码格式化，记得选上这个！( ) Unit Testing
 ( ) E2E Testing
 
######################################################

#【第 4 步】抉择 Vue 版本。本文应用了 3.x。? Choose a version of Vue.js that you want to start the project with
  2.x
> 3.x

######################################################

#【第 5 步】抉择标准计划。vue-cli 默认提供了几套标准，我抉择了 ESLint 标准规范
? Pick a linter / formatter config:
  ESLint with error prevention only
  ESLint + Airbnb config
> ESLint + Standard config  # ESLint 标准规范计划
  ESLint + Prettier

######################################################

#【第 6 步】抉择检测代码标准的操作（保留时，提交时），这里我都选上了。? Pick additional lint features: (Press <space> to select, <a> to toggle all, <i> to invert selection)
 (*) Lint on save  # 保留时检测
>(*) Lint and fix on commit  # 提交时检测

######################################################

#【第 7 步】你更喜爱把 Babel, ESLint 等配置放在哪里?  
? Where do you prefer placing config for Babel, ESLint, etc.? (Use arrow keys)
> In dedicated config files  # 独自的配置文件
  In package.json

######################################################

#【第 7 步】将此保留为将来我的项目的预设? 我选在不须要：n
? Save this as a preset for future projects? (y/N) n

通过漫长的期待，我的项目就创立胜利了。

运行我的项目：

cd 我的项目目录
npm run serve

ESLint 是代码检测工具，在上一步创立我的项目的操作中，咱们曾经把 ESLint 集成在我的项目中了。

不太革除 ESLint 的同学能够看官网介绍：『ESLint』

关上 根目录 下的 .eslintrc.js 文件能够看到默认的配置项。

module.exports = {
  root: true, // 以后文件是否在我的项目的根目录
  env: { // 启用 ESLint 检测的环境
    node: true // 在 node 环境下启动 ESLint 检测
  },
  extends: [ // 须要继承的根底配置项
    'plugin:vue/vue3-essential',
    '@vue/standard'
  ],
  parserOptions: { // 指明解析器
    parser: 'babel-eslint'
  },
  /*
   * 这里十分重要，我的项目的次要配置规定是写在这里的！！！！！！* 比方：在我的项目中是否容许应用 console？是否容许应用双引号包裹字符串？……
   *
   * "off" 或 0 - 敞开规定
   * "warn" 或 1 - 开启规定，应用正告级别的谬误：warn (不会导致程序退出)
   * "error" 或 2 - 开启规定，应用谬误级别的谬误：error (当被触发的时候，程序会退出)
   */
  rules: {
    'no-console': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
    'no-debugger': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
    'space-before-function-paren': 'off'
  }
}

当初的我的项目在 JS 里默认应用单引号包裹字符串，此时如果应用双引号就会报错。

能够尝试批改一下 App.vue

/* 省略局部代码 */
<script>
export default {name: "App"  // 此时这里应用了双引号}
</script>

当应用双引号包裹字符串时，ESLint 就会提醒如下谬误

E:\practice\vue\vue3\vue3-demo1\src\App.vue
  10:9  error  Strings must use singlequote  quotes

✖ 1 problem (1 error, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

会提醒呈现谬误的文件，行数，列数。而后给出一个提醒谬误 Strings must use singlequote quotes，意思是“字符串必须应用单引号”。

如果你的团队是习惯应用双引号，习惯在语句前面加分号，这些配置能够百度查查，本文不打算在 编码标准 上深刻解说，因为每个团队的格调不同。

Prettier 能主动帮你按标准格式化代码。『Prettier 中文网』

很多时候你的编码格调曾经造成习惯了，进入新团队后一下子难以改过来，如果经常出现 编码标准 的谬误揭示真的很影响开发速度。

此时 Prettier 就能够帮到你了。Prettier 能够在你保留时，依据你设置好的规定主动格式化代码。

我次要应用 VS Code 这款编辑器，所以能够间接在插件市场里找到 Prettier，间接点击装置即可。

装好 Prettier 插件后，就能够依据你我的项目标准的需要配置 主动格式化计划 了。

在我的项目 根目录 下创立 .prettierrc 文件，这个文件就是通知 Prettier 怎么格式化代码的。

外面能够写如下配置：

{
  // 不应用分号语法
  "semi": false,
  // 应用单引号
  "singleQuote": true,
  // 对象最初一行不加逗号
  "trailingComma": "none"
}

更多配置能够百度，也能够在『Prettier 中文网』查阅。

关上 VS Code 设置面板：文件 – 首选项 – 设置

而后在搜寻栏输出 save，之后勾选上 Editor: Format On Save 即可。

须要留神的是，如果配置完 ESLint 或 Prettier 不失效的话，请从新运行一下我的项目。

git commit 也要做到规范化，最好提供模板的形式提交。

后面讲的都是 编码时 的标准束缚，其实还有另一个标准是很多人没留神到的，它就是 版本信息 标准。

先来看看什么叫 好的标准：

每个记录都有性能阐明，而后再简略形容一下本次提交的阐明。

下面的例子看上去是很难受，但每次这样写会不会很麻烦？如何保障每个人都按同一个标准来写？比方：有人写“修复 bug”，有人写“修复破绽”。

应用“约定式提交标准”。

所谓的 约定式提交标准 其实就是提供一套模板让你抉择本次提交的大略方向，最初再简略写上一两句本次提交阐明即可。

约定式提交标准 被探讨得最多的就是的 Angular 团队标准延长出的 Conventional Commits specification（约定式提交）。有趣味能够看看。

约定式提交标准格局：

<type>[optional scope]: <description>

< 类型 >[可选 范畴]: < 形容 >

类型是一堆选项，不须要用户手动输出。这样就能够解决下面提到的其中一个问题。

用 Commitizen 和 cz-customizable 来实现。并且应用 git cz 来代替 git commit。

npm install commitizen cz-customizable -dev

应用下面这条命令就能够装置 commitizen 和 cz-customizable。

这里之所以不全局装置 -g，是因为新接手我的项目的搭档可能本人电脑自身没装置 commitizen。此时跟着我的项目中装置他也能够失常应用。

如果你是常常应用这种标准话提交的，倡议你全局装置 commitizen。

但 cz-customizable 还是倡议装置在我的项目中 -dev，这样能够不便每个我的项目独立配置。

在 package.json 中增加以下配置：

/* 省略局部代码 */
"config": {
  "commitizen": {"path": "node_modules/cz-customizable"}
}

在我的项目根目录下创立 .cz-config.js 文件，并增加以下配置：

module.exports = {
  // 可选类型
  types: [{ value: 'feat', name: '⚡ feat: 新性能'},
    {value: 'fix', name: '🐛 fix: 修复 Bug'},
    {value: 'docs', name: '✏️ docs: 文档变更'},
    {value: 'style', name: '💄 style: 不影响代码含意的变动(空白、格式化、短少分号等)' },
    {value: 'refactor', name: '♻️ refactor: 重构代码，既不修复谬误也不增加性能'},
    {value: 'perf', name: '⚡ perf: 性能优化'},
    {value: 'test', name: '✅ test: 测试相干'},
    {value: 'ci', name: '👷 ci: 更改继续集成文件和脚本'},
    {value: 'chore', name: '📦 chore: 从新打包或更新依赖工具等杂活'},
    {value: 'revert', name: '⏪ revert: 代码回退'},
    {value: 'WIP', name: '🚧 WIP: Work in progress'}
  ],
  // scope 类型（定义之后，可通过高低键抉择）scopes: [['components', '组件相干'],
    ['hooks', 'hook 相干'],
    ['utils', 'utils 相干'],
    ['element-ui', '对 element-ui 的调整'],
    ['styles', '款式相干'],
    ['deps', '我的项目依赖'],
    ['config', '配置相干'],
    ['other', '其余批改'],
    // 如果抉择 custom，前面会让你再输出一个自定义的 scope。也能够不设置此项，把前面的 allowCustomScopes 设置为 true
    ['custom', '以上都不是？我要自定义']
  ].map(([value, description]) => {
    return {
      value,
      name: `${value.padEnd(30)} (${description})`
    }
  }),

  // 步骤音讯提醒
  messages: {
    type: '确保本次提交遵循标准！\n 抉择你要提交的类型：',
    scope: '\n 抉择一个 scope（可选）：',
    customScope: '请输出批改范畴（可选）：',
    subject: '请输出变更形容（必填）：',
    body: '填写更加具体的变更形容（可选）：',
    footer: '请输出要敞开的 ISSUES（可选）：',
    confirmCommit: '确认提交？'
  },
  // 容许自定义范畴
  allowCustomScopes: true,
  // 要跳过的问题
  skipQuestions: ['footer'],

  // subject 文字默认值是 72
  subjectLimit: 100
}

此时就能够应用 git cz 来代替 git commit 了。

通过下面的配置后，能够应用 git add . 把变更内容提交到暂存区，而后再应用 git cz 提交一次版本。

git add .

git cz

输出完 git cz 后，就开始抉择提交的类型

抉择变更的范畴

之后还会有一系列的提醒，局部是规定必填的。

最初确认提交，就能够生成一个版本。

最初应用 git log 能够查看提交的历史记录。

airbnb 标准

google 标准

百度 EFE 标准

京东 Aotu 标准

JS 代码备注标准：JSDoc

阮一峰的 Commit message 和 Change log 编写指南

如果本文对你有帮忙，请帮我点个赞吧，同时你也能够把本文举荐给你的敌人。

本文由博客一文多发平台 OpenWrite 公布！

关于前端:前端规范落地团队级的解决方案

前言

规范化引发的问题

解决方案

入手解决

1、创立我的项目

1.1、应用 vue-cli 创立我的项目

2、配置 ESLint 规定

2.1 配置

2.2 测试

3、装置代码格式化插件 Prettier

3.1 装置 Prettier

3.2 配置计划

3.3 设置保留时主动格式化代码

4、约定式提交标准

4.1 好的标准！

4.2 遇到的问题

4.3 解决办法

4.4 入手实现

4.4.1 装置

4.4.2 配置

4.4.3 应用

标准参考