自动化代码规范工具

1 技术选型

1.1 痛点

在软件研发过程中，bug越早发现，成本越低。代码扫描和单元测试，就是在早期帮我们发现程序中问题的有效手段。代码扫描不仅能帮我们发现程序的漏洞，也能督促开发人员更规范优雅地写代码。
推动代码规范，提高代码质量，从源头把控软件产品质量，已经在研发体系形成共识。

在梳理公司前端应用时发现很多代码不规范的地方，包括简单的js问题以及代码格式问题，造成了代码可读性下降，可维护性降低，甚至对页面功能的实现和性能产生不好的影响。
例如线上出现的一个问题，其关键代码如下：

if (isValid) {
   
    function setAccount() {
   
        // code...
    }
}

在非函数的代码块内部声明函数，这在“strict”模式下是被禁止的，导致页面在低版本安卓和IOS系统下解析错误，无法正常渲染，影响客户使用业务。这一类的错误理应在开发阶段就得到问题提示，却遗漏到生产环境。

由于团队人数众多，合作开发，每个人风格各异，为了提高代码可读性、可维护性以及性能和兼容性，同时为了回避错误、小纠结和反模式，保证代码质量，便于团队协作，推行前端规范来对代码质量进行统一把控。主要针对的痛点如下：

1）代码规范落地难

部门曾采取过的方式有：

1. 编写文档类代码规范，比如word、wiki等形式，组织培训宣传，召集开发者进行学习；
2. 设置code review机制，合并代码时需要多人审查。

这两种方式，存在成本高、收益低、难度大等问题，代码规范审查容易慢慢流于形式，约束力逐渐降低。归根结底在于需要工具去强行保证代码必须经过开发规范的扫描。

2）低质量代码容易遗漏到线上

在实际开发过程中，开发人员可以很轻易地执行git push操作将本地代码推送到远程仓库。如果代码质量低下，就很容易对线上应用质量埋下隐患。在合并的时候再进行code review，问题积压较多，时间不够充分，反馈链路太长。
最好的方式是，本地进行commit的时候，保证当前代码能够满足团队制定的开发规范，如果不通过，commit则无法成功，这样可从源头保证代码质量。

3）代码格式难统一

各个开发成员的代码格式都有很大的不同，有人字符串喜欢用双引号，有人喜欢使用单引号等等。代码格式不统一，将会影响代码可读性，无疑也增加了团队内的沟通成本。仅靠开发者手动修改和开发时注意，效率不够高也容易有遗漏。需要有自动化工具来高效完成格式统一。

4）代码质量文化培养难

通过引入代码质量工具，在开发过程中能够时刻对自身代码质量进行约束，逐渐培养自身对代码质量有“洁癖”的开发观念，同时也会成为团队的质量文化。

1.2 技术栈选型

针对上述痛点，选择eslint + stylelint + prettier + yorkie + lint-staged这几个工具进行组合。以及搭配DevOps平台，对代码进行线下和线上双重检查。
要想防患于未然，防止将存在潜在问题的代码带到线上环境，最好的办法是在本地提交代码时就能够扫描出潜在的错误，并强制将其修改后才能提交，这样就能保证线上代码至少不会存在低级的程序错误。
其中yorkie就是通过git hooks实现强制在pre-commit阶段执行lint指令；lint-stage则保证git 暂存区的代码，即本次修改的代码可得到扫描检查；eslint和stylelint则是实际负责代码规范校验的工具；最后由prettier自动统一代码风格。

当违反所配置的规则，严重等级为error时，就不能提交成功，必须将其修改为符合规范的方可提交。确保最终提交到线上的代码符合代码规范、风格统一。

DevOps平台进行线上检查，还可以提供相关页面报告。

2 规则介绍

2.1 基础规则

eslint和stylelint的推