项目工程化：团队协作代码规范实践 commitizen husky

前言

近期接手了一个h5的web端编辑器项目，在开发的过程中经过了数不清的开发者，大家的思维方式和水平参差不齐，导致了以下几个对于项目代码稳健性和DX都影响很大的问题：

1. 代码风格
   • 每个人代码风格不同，let, var 满天飞，想用啥就用啥
   • 回调地狱的狂热爱好者，对async/await语法不熟悉导致的大量嵌套
2. 稳健性
   • 开发者对Vuex的了解不够深入，异步操作写在了mutation中，大量使用了this.dispatch语法，代码啰嗦
3. 可读性
   • 代码风格跟着思路从头走到尾，缺乏封装，导致有上千行的函数

问题归因

1. 项目人手不足。 常常需要招聘实习生给项目做需求，与此同时，项目的 Maintainer 对提交代码的 Code Review 做得不足，导致许多代码都是能跑就行地合到了 master 分支，逐渐积累下越来越多的技术债。

2. 代码风格缺乏硬性的制约。 在开发的流程中，只有在 Code Review 的时候提到过代码风格的问题，比如 var, let, const 的使用不当等等。过度依赖约定，导致许多规范并没有实际的行使下来。

3. 代码提交信息和分支命名不规范。 提交信息里面充斥着"update"，"修复bug"，这样的随意说明，没有 type 和scope ，在故障出现的时候没办法快速 review 到问题的直接原因。

4. 业务逻辑和UI逻辑没有分离。 项目整体的开发工程有多处没有遵循数据驱动视图渲染的准则，关于业务的逻辑（包括游戏场景的逻辑，接口数据的预处理等等）散落在了.vue，store和utils中，和UI无关的业务逻辑和视图的控制混合在一起，可读性很差。而且这样会导致代码缺乏封装，一个功能多处实现，且入口和出口模糊，一个 .vue 既是入口也是出口。

目标

1. 代码风格统一

在刚接手项目的时候，需要在原来开发到80%的功能模块继续开发，当我开始 review 的时候发现代码的可读性很差。例如：

• store 中的一个 action 长达数百行，多处 if-else 实现具体逻辑，缺乏封装。
• let, var 混用，不使用 const

于是配置更详细的 eslint 来解决该问题：

module.exports = {
  root: true,
  env: {
    node: true
  },
  extends: ["plugin:vue/essential", "@vue/standard"],
  globals: {
    qc: true,
    Phaser: true,
    Color: true
  },
  rules: {
    "no-console": "off",
    "no-debugger": process.env.NODE_ENV === "production" ? "error" : "off",
    // 没有重新赋值的变量使用 const 定义
    "prefer-const": ["error", {
      "destructuring": "any",
      "ignoreReadBeforeAssign": false
    }],
    // 禁止使用 var，使用 let、const 代替
  'no-var': 'error',
    // 限制块语句的最大可嵌套深度
  'max-depth': ['warn', 4],
    // 限制方法参数个数
  'max-params': ['warn', 3]
  },
  parserOpti：ons: {
    parser: "babel-eslint"
  },
  overrides: [
    {
      files: [
        "**/__tests__/*.{j,t}s?(x)",
        "**/tests/unit/**/*.spec.{j,t}s?(x)"
      ],
      env: {
        jest: true
      }
    }
  ]
};

其中，限制函数的行数，参数的个数，文件的最大行数，都可以间接强制开发者对代码进行精简，封装。

2. 代码提交规范统一

在实际开发的过程中，约定都是虚的，只有强制的lint才能规范好实际的产出。于是引入husky+commitlint组合拳。

为项目安装 commitlint ，运行在每次commit的时候运行 commitlint --edit $1 即可根据项目根目录配置的 .commitlintrc 来对提交的注释信息进行格式检查。与此同时，当然不能期望开发者会自行主动完成该动作，为了达到强制性，需要配置 git hooks 在 commit-msg 的时候自动运行 commitlint 校验，可以给项目安装 husky 更便捷地在 package.json 配置 git hooks。

为了更方便的填写规范的提交注释 type(scope): messages... ，可以使用 commitizen 工具，命令行对话式地生成提交注释。

具体可以参考我的模板，欢迎来⭐️：git-husky-commitizen-lab

多多指教！