代码风格检查
强规范团队主要用了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
14module.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
8const 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 template
ide插件,可以快速生成规范化的commit信息
不足的地方
没有引入Typescript
进行强约束,需要成本去学习,但是,随着越来越多的库逐渐使用ts语言编写,ts是一个不可回避的问题
范式约定还是扮演了比较重的角色