关于javascript:带你入门前端工程二统一规范

代码标准是指程序员在编码时要恪守的规定，标准的目标就是为了让程序员编写易于浏览、可保护的代码。

试想一下，一个几十万行代码的我的项目，存在几种不同的代码标准，浏览起来是什么感触？连代码缩进应用空格还是 Tab 都能引发不少程序员的争执，能够说对立代码标准是十分重要的事件。

对立代码标准除了方才所说的两点外，还有其余益处：

标准的代码能够促成团队单干
标准的代码能够升高保护老本
标准的代码有助于 code review（代码审查）
养成代码标准的习惯，有助于程序员本身的成长

当团队的成员都严格依照代码标准来写代码时，能够保障每个人的代码看起来都像是一个人写的，看他人的代码就像是在看本人的代码（代码一致性），浏览起来更加顺畅。更重要的是咱们可能意识到标准的重要性，并保持标准的开发习惯。

代码标准个别蕴含了代码格局标准、变量和函数命名标准、文档正文标准等等。

个别是指代码缩进应用空格还是 Tab、每行结尾要不要加分号、左花括号需不需要换行等等。

命名标准个别指命名是应用驼峰式、匈牙利式还是帕斯卡式；用名词、名词组或动宾构造来命名。

const smallObject = {} // 驼峰式，首字母小写
const SmallObject = {} // 帕斯卡式，首字母大写
const strName = 'strName' // 匈牙利式，前缀示意了变量是什么。这个前缀 str 示意了是一个字符串

变量命名和函数命名的侧重点不同。

变量命名的重点是表明这个变量“是什么”，偏向于用名词命名。而函数命名的重点是表明这个函数“做什么”，偏向于用动宾构造来命名（动宾构造就是 doSomething）。

// 变量命名示例
const appleNum = 1
const sum = 10

// 函数命名示例
function formatDate() { ...}
function toArray() { ...}

因为拼音同音字太多，千万不要应用拼音来命名。

文档正文比较简单，例如单行正文应用 //，多行正文应用 /**/。

/**
 * 
 * @param {number} a 
 * @param {number} b 
 * @return {number}
 */
function add(a, b) {return a + b}

// 单行正文
const active = true

如果要让团队从头开始制订一份代码标准，工作量会十分大，也不事实。所以强烈建议找一份比拟好的开源代码标准，在此基础上联合团队的需要作个性化批改。

上面列举一些比拟闻名的 JavaScript 代码标准：

airbnb (101k star 英文版)，airbnb- 中文版
standard (24.5k star) 中文版
百度前端编码标准 3.9k star

CSS 代码标准也有不少，例如：

styleguide 2.3k star
spec 3.9k star

标准制订下来了，那怎么确保它被严格执行呢？目前有两个办法：

应用工具校验代码格局。
利用 code review 审查变量命名、正文。

倡议应用这两个办法并行不悖，确保代码标准被严格执行。

上面让咱们来看一下，如何应用工具来校验代码格局。

ESLint 最后是由 Nicholas C. Zakas 于 2013 年 6 月创立的开源我的项目。它的指标是提供一个插件化的 javascript 代码检测工具。

下载依赖

// eslint-config-airbnb-base 应用 airbnb 代码标准
npm i -D babel-eslint eslint eslint-config-airbnb-base eslint-plugin-import

配置 .eslintrc 文件

{
    "parserOptions": {"ecmaVersion": 2019},
    "env": {"es6": true,},
    "parser": "babel-eslint",
    "extends": "airbnb-base",
}

在 package.json 的 scripts 加上这行代码 "lint": "eslint --ext .js test/ src/"。而后执行 npm run lint 即可开始验证代码。代码中的 test/ src/ 是要进行校验的代码目录，这里指明了要查看 test、src 目录下的代码。

不过这样查看代码效率太低，每次都得手动查看。并且报错了还得手动批改代码。

为了改善以上毛病，咱们能够应用 VSCode。应用它并加上适当的配置能够在每次保留代码的时候，主动验证代码并进行格式化，省去了入手的麻烦（下一节讲如何应用 VSCode 主动格式化代码）。

stylelint 是一个开源的、用于查看 CSS 代码格局的开源工具。具体如何应用请看下一节。

装置 VSCode，而后装置插件 ESLint。

抉择 File -> Preference-> Settings（如果装了中文插件包应该是文件 -> 选项 -> 设置），搜寻 eslint，点击 Edit in setting.json。

将以下选项增加到配置文件

    "editor.codeActionsOnSave": {"source.fixAll": true,},

配置完之后，VSCode 会依据你以后我的项目下的 .eslintrc 文件的规定来验证和格式化代码。

TypeScript

下载插件

npm install --save-dev typescript @typescript-eslint/parser @typescript-eslint/eslint-plugin

在 .eslintrc 配置文件，增加以下两个配置项：

module.exports = {
    parser: '@typescript-eslint/parser',
    plugins: ['@typescript-eslint'],
}

在根目录下的 package.json 文件的 scripts 选项里增加以下配置项：

"scripts": {"lint": "eslint --ext .js,.ts,.tsx test/ src/",},

test/ src/ 是你要校验的目录。批改完后，当初 ts 文件也能够主动格式化了。

扩大

如何格式化 HTML、Vue（或其余后缀）文件中的 HTML 和 CSS？

这须要利用 VSCode 自带的格式化，快捷键是 shift + alt + f。假如以后 VSCode 关上的是一个 Vue 文件，按下 shift + alt + f 会提醒你抉择一种格式化标准。如果没提醒，那就是曾经有默认的格式化标准了（个别是 vetur 插件），而后 Vue 文件的所有代码都会格式化，并且格式化规定还能够本人配置。

具体规定如下图所示，能够依据本人的爱好来抉择格式化规定。

因为之前曾经设置过 ESlint 的格式化规定了，所以 Vue 文件只须要格式化 HTML 和 CSS 中的代码，不须要格式化 JavaScript 代码，所以咱们须要禁止 vetur 格式化 JavaScript 代码：

依据上图配置实现后，回到方才的 Vue 文件。随便打乱代码的格局，再按下 shift + alt + f，会发现 HTML 和 CSS 中的代码曾经格式化了，然而 JavaScript 的代码并没格式化。没关系，因为曾经设置了 ESlint 格式化，所以只有执行保留操作，JavaScript 的代码也会主动格式化。

同理，其余类型的文件也能够这样设置格式化标准。

下载依赖

npm install --save-dev stylelint stylelint-config-standard

在我的项目根目录下新建一个 .stylelintrc.json 文件，并输出以下内容：

{"extends": "stylelint-config-standard"}

VSCode 增加 stylelint 插件：

而后就能够看到成果了。

如果你想批改插件的默认规定，能够看官网文档，它提供了 170 项规定批改。例如我想要用 4 个空格作为缩进，能够这样配置：

{
    "extends": "stylelint-config-standard",
    "rules": {"indentation": 4}
}

代码审查是指让其他人来审查本人代码的一种行为。审查有多种形式：例如结对编程（一个人写，一个人看）或者对立某个工夫点大家相互做审查（单人或多人）。

代码审查的目标是为了查看代码是否合乎代码标准以及是否有谬误，另外也能让评审人理解被审人所写的性能。常常相互审查，能让大家都能更清晰地理解整个我的项目的性能，这样就不会因为某个外围开发人员到职了而引起我的项目延期。

当然，代码审查也是有毛病的：一是代码审查十分耗时，二是有可能引发团队成员争吵。据我理解，目前国内很多开发团队都没有代码审查，包含很多大厂。

集体倡议在找工作时，能够询问一下对方团队是否有测试标准、测试流程、代码审查等。如果同时领有以上几点，阐明是一个靠谱的团队，能够优先选择。

git 标准个别包含两点：分支治理标准和 git commit 标准。

个别我的项目分主分支（master）和其余分支。

当有团队成员要开发新性能或改 BUG 时，就从 master 分支开一个新的分支。例如我的项目要从客户端渲染改成服务端渲染，就开一个分支叫 SSR，开发完了再合并回 master 分支。

如果要改一个重大的 BUG，也能够从 master 分支开一个新分支，并用 BUG 号命名。

# 新建分支并切换到新分支
git checkout -b test
# 切换回主分支，合并新分支
git checkout master
git merge test

留神，在将一个新分支合并回 master 分支时，如果新分支中有一些意义不明确的 commit，倡议先对它们进行合并（应用 git rebase）。合并后，再将新分支合并回 master 分支。

git 在每次提交时，都须要填写 commit message。

git commit -m 'this is a test'

commit message 就是对你这次的代码提交进行一个简略的阐明，好的提交阐明能够让人一眼就明确这次代码提交做了什么。

既然明确了 commit message 的重要性，那咱们就更要好好的学习一下 commit message 标准。上面让咱们看一下 commit message 的格局：

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

咱们能够发现，commit message 分为三个局部 (应用空行宰割):

题目行（subject）: 必填, 形容次要批改类型和内容。
主题内容（body）: 形容为什么批改, 做了什么样的批改, 以及开发的思路等等。
页脚正文（footer）: 能够写正文，放 BUG 号的链接。

commit 的类型：

feat: 新性能、新个性
fix: 批改 bug
perf: 更改代码，以进步性能
refactor: 代码重构（重构，在不影响代码外部行为、性能下的代码批改）
docs: 文档批改
style: 代码格局批改, 留神不是 css 批改（例如分号批改）
test: 测试用例新增、批改
build: 影响我的项目构建或依赖项批改
revert: 复原上一次提交
ci: 继续集成相干文件批改
chore: 其余批改（不在上述类型中的批改）
release: 公布新版本
workflow: 工作流相干文件批改

commit message 影响的性能或文件范畴, 比方: route, component, utils, build…

commit message 的概述

具体批改内容, 能够分为多行.

一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.

fix（修复 BUG）

每次 git commit 最好加上范畴形容。

例如这次 BUG 修复影响到全局，能够加个 global。如果影响的是某个目录或某个性能，能够加上该目录的门路，或者对应的性能名称。

// 示例 1
fix(global): 修复 checkbox 不能复选的问题
// 示例 2 上面圆括号里的 common 为通用治理的名称
fix(common): 修复字体过小的 BUG，将通用治理下所有页面的默认字体大小批改为 14px
// 示例 3
fix(test): value.length -> values.length

feat（增加新性能或新页面）

feat: 增加网站主页动态页面

这是一个示例，假如对工作动态页面进行了一些形容。这里是备注，能够是放 BUG 链接或者一些重要性的货色。

chore（其余批改）

chore 的中文翻译为日常事务、例行工作。顾名思义，即不在其余 commit 类型中的批改，都能够用 chore 示意。

chore: 将表格中的查看详情改为详情

其余类型的 commit 和下面三个示例差不多，在此不再赘述。

利用 git hook 能在特定的重要动作产生时触发自定义脚本。

验证 git commit 标准也不例外，咱们须要通过 git 的 pre-commit 钩子函数来进行。当然，你还须要下载一个辅助插件 husky 来帮忙你进行验证。

pre-commit 钩子在键入提交信息前运行，它用于查看行将提交的快照。

husky 是一个开源的工具，应用它咱们能够在 package.json 里配置 git hook 脚本。上面让咱们看一下如何应用：

下载

npm i -D husky

在 package.json 加上上面的代码：

"husky": {
  "hooks": {
    "pre-commit": "npm run lint",
    "commit-msg": "node script/verify-commit.js",
    "pre-push": "npm test"
  }
}

而后在你我的项目根目录下新建一个文件夹 script，并在上面新建一个文件 verify-commit.js，输出以下代码：

const msgPath = process.env.HUSKY_GIT_PARAMS
const msg = require('fs')
.readFileSync(msgPath, 'utf-8')
.trim()

// 提前定义好 commit message 的格局，如果不合乎格局就退出程序。const commitRE = /^(feat|fix|docs|style|refactor|perf|test|workflow|build|ci|chore|release|workflow)(\(.+\))?: .{1,50}/

if (!commitRE.test(msg)) {
    console.error(`
        不非法的 commit 音讯格局。请查看 git commit 提交标准：https://github.com/woai3c/Front-end-articles/blob/master/git%20commit%20style.md
    `)

    process.exit(1)
}

当初来解释下各个钩子的含意：

"pre-commit": "npm run lint"，在 git commit 前执行 npm run lint 查看代码格局。
"commit-msg": "node script/verify-commit.js"，在 git commit 时执行脚本 verify-commit.js 验证 commit 音讯。如果不合乎脚本中定义的格局，将会报错。
"pre-push": "npm test"，在你执行 git push 将代码推送到近程仓库前，执行 npm test 进行测试。如果测试失败，将不会执行这次推送。

通过工具，咱们能够很好的治理团队成员的 git commit 格局，无需应用人力来查看，大大提高了开发效率。

另外，我提供了一个简略的工程化 DEMO。它蕴含了主动格式化代码和 git 验证，如果看完文章还是不晓得如何配置，能够参考一下。

我的项目标准次要是指我的项目文件的组织形式和命名形式。对立我的项目标准是为了方便管理与批改，不会呈现同样性质的文件呈现在不同的中央。例如同样是图片，一个呈现在 assets 目录，一个呈现在 img 目录。

创立目录，须要依照用处来划分。例如较常见的目录有：文档 doc、资源 src、测试 test…

├─doc
├─src
├─test

src 资源目录又能够细分：

├─api
├─asset
├─component
├─style
├─router
├─store
├─util
└─view

当初文件命名有很多种形式（是否简写 img image、是否复数 img imgs、文件名过长是用驼峰还是用 - 连贯 oneTwo one-two）。其实用哪种形式不重要，最重要的是命名形式肯定要对立。

例如团队成员有人命名目录喜爱用复数模式（apis），有人喜爱用复数（api），这样是不容许的，肯定要对立。

留神，这里的 UI 标准是指我的项目里罕用 UI 组件的体现形式以及组件的命名形式，而不是指 UI 组件如何设计。

当初开源的 UI 组件库有很多，不同的组件库的组件体现形式也不一样。例如有些按钮组件点击时色彩变深，有些组件则是变浅。所以倡议在 PC 端和挪动端都应用对立的 UI 组件库（PC 端、挪动端各一个），或者同一个我的项目里只应用一个 UI 组件库。

另外，我的项目里罕用的组件体现形式也须要通过文档确定下来。例如膨胀开展的动画成果，具体到动画持续时间、动画是缓进快出还是快进缓出等等。

如果不把这些体现形式的标准确定下来，就有可能呈现以下这种状况：

同样的组件，在不同的页面有不同的体现形式（例如动画成果）。因为没有标准，开发依据集体爱好增加体现成果。
同样的二次确认弹窗，提醒语不一样，按钮类型也不一样。

对立命名，也是为了缩小沟通老本。

举个例子，当初的日期组件能够选单个日期、也能够抉择范畴日期，有的还能够抉择工夫。这样一来，一个日期组件就有四种状况：

单个日期带工夫
单个日期不带工夫
日期范畴带工夫
日期范畴不带工夫

如果这种状况不辨别好，开发在看产品文档的时候就会纳闷，从而减少了开发与产品的沟通老本。

综上所述，咱们能够发现制订 UI 标准的益处有两点：

对立页面 UI 规范，节俭 UI 设计工夫。
缩小沟通老本，进步前端开发效率。

其实对立标准的最基本目标就是为了保障团队成员的一致性，从而缩小沟通老本，进步开发效率。我以前就经验过因为标准不规范，造成产品与开发了解有偏差、开发各写各的代码，导致各种 BUG 一直，最初我的项目延期的事。

所以说为了进步开发效率，缩小加班，请肯定要对立标准。

husky
stylelint
eslint

带你入门前端工程全文目录：

技术选型：如何进行技术选型？
对立标准：如何制订标准并利用工具保障标准被严格执行？
前端组件化：什么是模块化、组件化？
测试：如何写单元测试和 E2E（端到端）测试？
构建工具：构建工具有哪些？都有哪些性能和劣势？
自动化部署：如何利用 Jenkins、Github Actions 自动化部署我的项目？
前端监控：解说前端监控原理及如何利用 sentry 对我的项目履行监控。
性能优化（一）：如何检测网站性能？有哪些实用的性能优化规定？
性能优化（二）：如何检测网站性能？有哪些实用的性能优化规定？
重构：为什么做重构？重构有哪些手法？
微服务：微服务是什么？如何搭建微服务项目？
Severless：Severless 是什么？如何应用 Severless？

关于javascript:带你入门前端工程二统一规范

代码标准

如何制订代码标准

代码格局

命名标准

文档正文

如何查看代码标准

ESLint

stylelint

应用 VSCode 主动格式化代码

格式化 JavaScript 代码

TypeScript

扩大

格式化 CSS 代码

Code Review 代码审查

git 标准

分支治理标准

git commit 标准

type

scope

subject

body

footer

示例

fix（修复 BUG）

feat（增加新性能或新页面）

chore（其余批改）

验证 git commit 标准

我的项目标准

UI 标准

体现形式

对立命名

小结

参考资料