如何保证前端项目代码质量

What

什么是代码自己的质量?

代码自己的质量: 包括复杂度, 重复率, 代码风格等。

• 复杂度: 项目代码量，模块大小，耦合度等
• 重复率: 重复出现的代码区块占比，一般要求在5%如下(借助平台化工具如Sonar)
• 代码风格: 代码风格是否统一(动态语言代码如JS, Python风格不受约束)

代码质量降低恶性循环

常见的代码质量降低的缘由:

• 破罐破摔: 在烂代码上迭代代码罪恶感比较小
• 传染性: 不在乎代码质量, 只关注业务的产出
• 爱莫能助

常见的致使恶性循环的场景:

• 业务压力太大

烂代码产生的常见缘由是业务压力大，致使没有时间或意愿讲究代码质量。由于向业务压力妥协而生产烂代码以后，开发效率会随之降低，进而致使业务压力更大，造成一种典型的恶性循环。

• 经过增长人力解决业务压力

为了应对业务压力，常见的作法就是向项目中增长人力，可是单纯地增长人力的话，会由于风格不一致、沟通成本上升等缘由致使烂代码更多。

那么咱们应该如何解决呢?

这是一个长期坚持的过程。

代码质量管控四个阶段

• 规范化

创建代码规范与Code Review制度

1. airbnb
2. standard
3. node-style-guide
4. google javascript style guide
5. google html/css style guide
6. Vue风格指南

我以为统一项目目录结构也是规范化的一种(好比咱们用脚手架建立项目模板), 一个规范化的目录结构大大下降新人的上手成本。

• 自动化

使用工具(linters)自动检查代码质量。

• 流程化

将代码质量检查与代码流动过程绑定。

质量检查与代码流动绑定后的效果：

备注:

1. 编辑时候: 经过编辑器插件, 实时查看质量检查

2. 能够利用CI(Jekins/Travis)把构建发布过程搬到线上, 先跑代码扫描, 测试代码等, 而后没有错误再进行build, build成功经过ssh推到服务器。
复制代码

• 中心化

以团队总体为视角，集中管理代码规范，并实现质量情况透明化。

当团队规模愈来愈大，项目愈来愈多时，代码质量管控就会面临如下问题：

1. 不一样项目使用的代码规范不同

2. 部分项目因为放松要求，没有接入质量检查，或者存在大量未修复的缺陷

3. 没法从团队总体层面上体现各个项目的质量情况对比

为了应对以上问题，须要建设中心化的代码质量管控体系，要点包括：

代码规范统一管理。经过脚手架命令垂直管理代码扫描配置规则集, 自动安装，不在本地写规则。一个团队、一类项目、一套规则。

---

• [待定] 使用统一的持续集成服务(Jekins/Travis等)。质量检查不经过的项目不能上线。

• [待定] 创建代码质量评分制度(借助Sonar)。让项目与项目之间可以横向对比，项目自身可以纵向对比，而且进行汇总反馈。

Why

代码质量是团队技术水平和管理水平的直接体现。

看代码的时间远远多于写代码的时间

目前前端项目出现的问题

• 书写风格不统一, 阅读体验差
• 维护性差, 复用性差(Code Review互相进步)
• 容易出现低质量代码, 代码返工率高
• git commit不规范

How

经过哪些手段来保证代码质量?

EditorConfig

EditorConfig在多人协做开发项目时候, 支持跨编辑器, IDE来支持维护一致的编码样式(文件格式)。

VSCode插件EditorConfig for VS Code提供一键生成.editorconfig。

查看实例。

TypeScript

• 官网介绍。
• 中文awesome-typescript
• TypeScript体系调研报告
• 2018年度JS趋势报告

Git Hooks

Git能在特定的重要动做发生时触发自定义脚本。 有两组这样的钩子：客户端的和服务器端的。 客户端钩子由诸如提交和合并这样的操做所调用，而服务器端钩子做用于诸如接收被推送的提交这样的联网操做, 咱们目前使用的大多数是客户端钩子。

经过husky集成git hooks, 若是对git想有更全面的理解推荐阅读GIt文档。

husky会安装一系列的git hook到项目的.git/hook目录中。

下面两张图分别对比没有安装husky与安装了husky的git目录区别:

当你用 git init 初始化一个新版本库时，Git 默认会在这个目录中放置一些示例脚本(.sample结尾的文件)。

pre-commit

pre-commit 钩子在键入提交信息前运行。 它用于检查即将提交的快照，你能够利用该钩子，来检查代码风格是否一致（运行相似 lint 的程序。

• lint-staged: 能够获取全部被提交的文件并执行配置好的任务命令,各类lint校验工具能够配置好lint-staged任务中。
• prettier: 能够配置到lint-staged中, 实现自动格式化编码风格。
• stylelint
• eslint
• tslint
• eslint-plugin-vue: Vue.js官方推荐的lint工具

关于为何选择prettier, 以及eslint 与prettier区别?。

关于prettier配置。 关于stylelint配置。 关于eslint配置。

commit-msg

• commitlint。

commit-msg 能够用来在提交经过前验证项目状态或提交信息, 使用该钩子来核对提交信息是否遵循指定的模板。

关于git hooks在package.json配置:

测试

unittest

• Jest
• Mocha

e2e

• Nightwatch
• Cypress

CHANGELOG

更新日志, standard-version。

Code Review

• [待定] Review制度,咱们目前公司在代码merge时候多人审核才经过。

如何快速落地到当前业务

前端脚手架(xx-cli)

采用中心化集中管理代码扫描配置文件的思路, 把code lint配置文件作成一个npm包发到内网, 而后扩展脚手架命令一键执行下发远程配置文件到本地项目, 而且把新增的package.json依赖打进来, 你们后面再安装新的依赖便可。

所谓中心化管理: 全部项目代码配置文件以远程配置文件为准, 若是你本地有同名配置会被删除, 这样方便后续咱们更新配置文件好比(增长vw/vh适配), 以及全部业务同步问题。

目前只有基于vue.js项目的lint脚本命令, 后续有别的项目, 考虑经过

dc-cli lint -- vue
dc-cli lint -- node
扩展
复制代码

demo演示

demo演示如何在旧项目中植入代码质量检测? 因为这部分是在内网演示就不发不出来了。

至于脚手架能够参考我以前的demoeasy-cli。这是比较全的demo。

Future

Jekins自动化

Sonar

Github:

SonarQube 是一款领先的持续代码质量监控平台，开源在github 上，能够轻松配置在内网服务器，实时监控代码，帮助了解提高提高团队项目代码质量。经过插件机制，SonarQube能够继承不一样的测试工具，代码分析工具，以及持续集成工具。

与持续集成工具（例如 Hudson/Jenkins 等）不一样，SonarQube 并非简单地把不一样的代码检查工具结果（例如 FindBugs，PMD 等）直接显示在 Web 页面上，而是经过不一样的插件对这些结果进行再加工处理，经过量化的方式度量代码质量的变化，从而能够方便地对不一样规模和种类的工程进行代码质量管理。

行业内提到"代码质量管理, 自动化质量管理", 通常指的都是经过Sonar来实现。

用Sonar可以实现什么?

• 技术债务(sonar根据"规则"扫描出不符合规则的代码)
• 覆盖率(单元测试覆盖率)
• 重复(重复的代码, 有利于提醒封装)
• 结构
• …

sonarjs

sonar支持多种编程语言, 其中包括JavaScript. 如sonarjs

最后打个广告,欢迎关注个人公众号 全栈小窝。