前端代码规范化实践

代码风格检查

强规范团队主要用了eslint + husky + 自定义检验代码 方式

eslint

团队使用了eslint的两个插件,分别是plugin:vue/recommended, eslint:recommended, 具体的eslint规则借鉴了eslint-config-vue这个仓库的配置规则

.eslintrc文件示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
module.exports = {
//...
extends: ['plugin:vue/recommended', 'eslint:recommended'],
rules: {
"vue/max-attributes-per-line": [2, {
"singleline": 10,
"multiline": {
"max": 1,
"allowFirstLine": false
}
}],
// 具体看 https://github.com/vuejs/eslint-config-vue
}
}

husky

在本地commit之前,使用husky做一次eslint校验,使用很简单
修改package.json文件

1
2
3
4
5
6
7
8
9
10
11
"husky": {
"hooks": {
"pre-commit": "node .commitLint.js && lint-staged"
}
},
"lint-staged": {
"src/**/*.{js,vue}": [
"eslint",
"git add"
]
}

针对Git提交的自定义校验

上文中,在pre-commit命令中,我们使用node执行了一个js文件,这个js文件里的内容就是我们自定义的一些规则了
由于开发时,经常会出现有人修改全局前缀地址的问题,这里我们做了一个校验,如果当前config文件被修改提交,那么本次commit就会失败
并提示
.commitLint.js

1
2
3
4
5
6
7
8
const cp = require('child_process')

cp.exec('git diff --cached --name-only --diff-filter=M -- "*/baseurl.js"', (code, stdout, stderr) => {
if (stdout.includes('baseurl')) {
console.log('检测到配置修改,提交失败')
return process.exit(1)
}
})

开发方面

组件设计

由于信奉同一件事,不做两遍的原则。在每次开发前,我并没有在产品需求会之后就开始直接分配任务让组员直接做,而是先把页面元素分析一边,找出共性组件(样式,功能),将页面分成一个个模块,按照页面模块去分配任务,这样子做有几个好处:

  • 有效减少开发工作量
  • 提升组件接口设计能力
  • 统一有效管理(如日期控件,业务上的选择控件等,需要一个统一的数据源)

全局状态/本地缓存管理

未经商讨,不允许在全局状态管理或者本地缓存中加入状态,这样做的唯一目的就是统一管理,防止混乱

抽出公共方法,写成工具库或者指令库

这也是总结最佳实践的一种形式

项目wiki的维护

使用gitlab提供的wiki功能,可以维护编写项目的知识管理
如:
https://code.odrcloud.cn/sham-litigation/js-sham-litigation/js-sham-litigation-web/-/wikis/home
https://code.odrcloud.cn/sham-litigation/sham-litigation/sham-litigation-web/-/wikis/%E4%BD%BF%E7%94%A8d3%E5%88%9B%E5%BB%BA%E5%9C%B0%E5%9B%BE%E4%BB%A5%E5%8F%8A%E5%AE%9E%E7%8E%B0%E4%B8%8B%E9%92%BB

总结最佳实践

如套路贷项目中,比较常见的是表单筛选页面,类似这样的页面,其实写法可以说是大差不差的,这种情况我们就可以将代码约束成范式

注释

必要的注释是必须的,data里的变量,必须写注释

代码提交

使用Git commit templateide插件,可以快速生成规范化的commit信息

不足的地方

没有引入Typescript进行强约束,需要成本去学习,但是,随着越来越多的库逐渐使用ts语言编写,ts是一个不可回避的问题

范式约定还是扮演了比较重的角色

关于组件化的思考