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

49次阅读

共计 7765 个字符,预计需要花费 20 分钟才能阅读完成。

代码标准

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

试想一下,一个几十万行代码的我的项目,存在几种不同的代码标准,浏览起来是什么感触?连代码缩进应用空格还是 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

如何查看代码标准

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

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

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

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

ESLint

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

  1. 下载依赖
// eslint-config-airbnb-base 应用 airbnb 代码标准
npm i -D babel-eslint eslint eslint-config-airbnb-base eslint-plugin-import
  1. 配置 .eslintrc 文件
{
    "parserOptions": {"ecmaVersion": 2019},
    "env": {"es6": true,},
    "parser": "babel-eslint",
    "extends": "airbnb-base",
}
  1. package.jsonscripts 加上这行代码 "lint": "eslint --ext .js test/ src/"。而后执行 npm run lint 即可开始验证代码。代码中的 test/ src/ 是要进行校验的代码目录,这里指明了要查看 testsrc 目录下的代码。

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

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

stylelint

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

应用 VSCode 主动格式化代码

格式化 JavaScript 代码

装置 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 的代码也会主动格式化。

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

格式化 CSS 代码

下载依赖

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}
}

Code Review 代码审查

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

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

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

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

git 标准

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 标准

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 分为三个局部 (应用空行宰割):

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

type

commit 的类型:

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

scope

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

subject

commit message 的概述

body

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

footer

一些备注, 通常是 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 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)
}

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

  1. "pre-commit": "npm run lint",在 git commit 前执行 npm run lint 查看代码格局。
  2. "commit-msg": "node script/verify-commit.js",在 git commit 时执行脚本 verify-commit.js 验证 commit 音讯。如果不合乎脚本中定义的格局,将会报错。
  3. "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 组件如何设计。

体现形式

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

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

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

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

对立命名

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

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

  1. 单个日期带工夫
  2. 单个日期不带工夫
  3. 日期范畴带工夫
  4. 日期范畴不带工夫

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

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

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

小结

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

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

参考资料

  • husky
  • stylelint
  • eslint

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

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

正文完
 0