除了代码规范，企业做前端还有啥规范

前端开发者需要建立和遵守哪些规范，有什么好处

 

为什么需要规范，规范能给我们带来什么好处,如果没有规范会造成什么后果?这里主要拿代码规范来说。

 

统一代码规范的好处:

1.提高代码整体的可读性、可维护性、可复用性、可移植性和可靠性，这会从根本.上降低开发成本，也是最重要的-一点。
2.保证代码的一致性:软件系统中最重要的因素之一-就是编码的一 致性。如果编码风格一致， 也更加易于维护，因为团队内任何人都可以快速理解并修改。
3.提升团队整体效率:开发人员通常需要花费大量的时间来解决代码质量问题，如果都按照规范编写,也有助于团队尽早发现问题，甚至完全预防问题，这将提高整个交付过程的效率。
4.减少code review期间一系列的争议， 因为缺乏标准，在争议过程中双方很难妥协(没少因为这事争论过)。

 

若不统一代码规范，可能会造成的后果:

1.由于缺乏规范，导致代码风格不一， 增加团队成员间的心理负担，极端情况下，某段
代码只有某个人能修改。
2.团队间协作更加困难:因为开发人员得适应不同的风格，会导致效率低下(阅读代码是我们花费时间最多的地方)。
3.在code review期间可能经常为类似的事情做过多的讨论。
4.影响团队的生产力和质量，严重的甚至会影响团队和谐。

 

为什么依然有很多团队缺乏规范

 

在这件事上，很难达成一致是我认为最重要的原因。并且,仅仅只是拥有规范也是不够的:

 

●当开发人员被要求在短时间内完成任务时,通常会回避质量标准。

●团队中总是有一些有个性的人不会为 了团队去改变自己的习惯。

●有些人在会议上就约定达成了-致,在会下依旧我行我素。

 

如何保持规范

1.对规范问题进行归纳分析并通过文档记录(wiki等) ，寻找业内最佳解决方案,在团队内进行统一。
2.采用小步快跑的方式，有问题就解决问题，按照优先级 和重要性进行排序划分，依次将问题纳入迭代，每个迭代重点解决其中几个即好。
3.本迭代的规范问题绝不留到下个迭代,防止堆积(当然，有时候还是得向项目经理妥协)。
4.在code review过程中严格把关,拒绝睁一只眼闭一只眼。
5.当团队成员对具体某个规范有争议时,及时讨论并定出结论。
6.没有规则只是为了 规则，制定规范的目的并不是一定要按照某某标准来执行，更多的是
团队成员达成一致即可。
7.鼓励大家大胆的质疑规则，若不能提高代码的可读性,可维护性,可复用性，可移植
性和可靠性的规则都应该被受到质疑。
8.以身作则，船头的方向不能偏航。
经过两个月的迭代后，发现效果出奇的好,大家的规范意识普遍增强，当遇到规范问题
时也不再畏畏缩缩，而是大胆的抛出在群里讨论。
 

开发者需要建立和遵守的规范

大致可以划分成这几个方向:
●开发流程规范
●代码规范
●git commit规范
●项目文件结构规范
●UI设计规范
 

1.开发流程规范
这里可能有小伙伴有疑问了，开发流程规范不是项目经理定的吗国，跟我有什么关系?
这里想告诉大家的是，开发流程在一定程度 上应该是由我们自己来掌控。不管是传统开发的模式还是敏捷开发的模式，对于开发者来说核心依旧是高质高效的完成用户提出的需求。

笔者曾见过不少开发者在拿到产品经理的需求后就开始急匆匆的写代码，以此来体现他们的高效,但往往却因为需求理解不到位和前期代码欠缺设计导致bug率高和返工。

如何找到适合自己的开发流程是需要依靠经验来支撑的，需要反复总结和思考,最终达到高质高效完成的目的。
说一说笔者自己比较喜欢的开发流程:

在接收到需求后应第一时间去了解这个需求的背景是什么?这么做到底有没有解决用户的痛点?或者说用户更深层次的需求是什么?如果团队的产 品经理经验不丰富，往往可以在这个阶段砍掉很多不合理的需求(这一点 真的很重要)。

对于复杂大功能往往还需要进行技术方案调研和技术方案设计，并输出详细的设计文档。涉及到细节上，则需要将数据流走向、组件设计等通过脑图的形式呈现出来。
 

2.代码规范之格式化规范
由于每个开发者的IDE不同，即使IDE相同也会因为每个人的配置不一样导致格式化的结果
不一样。如何确保团队内开发人员采用统一的格式化配置呢?
这里给推荐大家使用prettier, 它内置了一套格式化的规则，具体配置:
1).安装依赖:

2).创建- -个空配置文件,让编辑器和其他工具知道你正在使用Prettier:

3).创建- -个.prettierignore[3]文件,让Prettier CLI和编辑器知道哪些文件不能格式化,
example:

4).配置编辑器(VScode为例)

找到IDE中设置模块，搜索format On Save,勾上这个就可以了。

现在当我们Ctrl + S保存代码时,插件就会帮助我们自动格式化了。
这里有小伙伴要问了，要是有人将没有格式化的代码提交上去怎么办?
这时候就需要在git commit的阶段自动将提交的代码进行格式化，这里我们借助工具husky,它主要可以帮助我们在git 阶段检查提交消息、运行测试、检查代码等。没接触过的小伙伴可以去官网了解一下，配置如下:
●安装husky和lint-staged :

●然后将以下内容添加到package. json 中:

这段配置的意思是:当执行git commit阶段前，先执行lint-staged，lint-staged 中的内容就是对暂存区的文件执行格式化的命令。

其他:若使用的是脚手架工具搭建的项目，会自带eslint配置 ( eslintConfig)。prettier和eslint 会有- -些配置上的冲突，这个时候需要安装eslint-config prettier[9]以使ESLint和Prettier相互配合,安装完后在. eslintrc中配置(以Create-React-App为例) :

这样就可以用"prettier"的部分规则覆盖前面的规则，让它们都能正常工作。
更多详情见: Prettier.
 

3.代码规范之JS/TS规范
JS/Ts主流的大致有这几种:
●Airbnb JavaScript Style Guide
●Google JavaScript style Guide
●ldiomatic JavaScript style Guide
●JavaScript Standard Style Guide
●jQuery JavaScript style Guide
比较推荐使用Airbnb JavaScript style Guide,它在Github.上足有12万star,几乎覆盖了
JavaScript的每一项特性。
具体配置:
1).安装依赖

2).生成配置文件

跟着终端中的提示，按照自身需求一步步选择即可。
有了具体的规范后，我们同样需要使用工具去约束:还是通过在git commit 阶段校验,若
不通过则取消提交。
配置(还是在package. json中的lint-staged ) :

注意:这里如果选用的Typescript, 则会默认使用@typescript-eslint/parser解析器，官方为了追求更快的解析速度，并不会对.ts文件中的类型进行检查，只会做语法检测。如果需要对类型也进行检测，需要在extends中加 上plugin:typescript-eslint/recommended-equiring type-checking[16]。但是在笔者的使用中发现效果并不好，-些基本的类型依然检测不出来，索性这里换了另一种方式:在pre commit 执行yarn run tsc ，这里的意思是对项目中ts文件进行类型检测，默认会读取根目录中的tsconfig. json配置。这种方式并不完美，它的弊端就在于全量检测，如果项目不大还好，若是项目代码量够多，检测10-20s也是常有的事。

4.代码规范之CSS规范
CSS检查代码规范使用stylelint 插件,规范则推荐使用stylelint config standard[18]:
1).安装

2).在项目的根目录中创建一个配置文件. stylelintre. json,内容如下:

3).解决与prettier配置的冲突:

4).将下面配置复制到. stylelintre. json中:

5).在git commitv阶段进行检测:

 

5.代码规范之自定义其他规范css
下面列一些团队内定的其他规范:
(1)命名规范
变量的命名中应尽量减少缩写的情况发生，做到见名知意。

(2)写注释
在每个文件的顶部明确说明该组件做什么，有没有业务理解难点等等,对业务特殊函数/变量也需要写注释