前端团队如何做规范

5,477 阅读7分钟

背景和设想

任何团队,规范都是怎么也绕不开的话题,我们有太多的理由去做规范,同时我们在做规范这件事上也有太多的痛点,那么有没有这样的一种方式,让规范这一件事情既能很好的落实,又对于我们的研发效能不会有什么影响?

任何事情,我们得知道,到底这件事情的难点在哪里?

1、针对规范本身而言。

规范理解不统一的问题。团队中的每一个人,对规范的理解是不统一的,比如定义一个常量,有些人喜欢用大写字母,有些人觉得不用纠结这个细节。有时候,大家对规范的边界理解,也是不统一的,有些人认为,我们的规范就是我们编码层面的规范,有些人认为,规范应当还包括工程层面的东西,比如项目的文件目录结构到底是怎么样的。

人力成本的问题。我们定义了规范,我们需要遵守相关的规范,那人力成本可能就会增加,比如我们要求代码结尾需要有分号,有些时候我们忘了加这个分号,我们要求要遵循驼峰命名,但是有时候就没有遵循。所以我们需要做代码review。

落地难的问题。每个人都有自己的编码习惯,统一的风格必定会导致团队内部的差异性。项目周期会有紧有松,导致真实落地的时候,就会出现现实与理想的割裂感。

2、针对团队来说

我们可能会有这么一些问题:我们的团队技术栈不统一,很多公共的建设没法开展;团队中没有完善的文档建设,大家没法形成一个统一的规范共识;规范落地的过程,难度很大,成本很高;在规范相关的制度上,我们可能也没有相关的制度保障。

关于规范,我们云积分的设想

image.png

如上图所示

我们云积分针对规范,把规范划分为三层,分别是规范的定义、规范的模板、规范的工具。

1、规范的定义

规范包含的内容,多种多样,比如有针对GIT的规范、CSS的规范、JS的规范等等。

我们把这些规范定义下来,直接通过第三方工具,自动化进行代码的lint校验、COMMIT Msg校验等等。

原理是什么呢?原理就是我们把这些基础的规范,在GIT提交的周期钩子中,先进行校验通过,通过了之后,才能commit成功。同时我们提供相关的命令行工具,直接针对我们不规范的代码,直接格式化的处理,尽最大的可能性,减少人工在这个过程中的精力耗费。

2、规范的模板

我们云积分是这么理解规范的,就是所谓的规范,一定是某个项目的规范,我们需要针对我们定义的所有规范,直接集成到我们的项目模板中。

比如在一个Vue的模板仓库中,我们针对这个仓库,集成了GIT COMMIT校验、ESlint校验、Stylelint校验、目录结构的预定义、相关的公用库的选择、自己团队内部的组件库、工具库等等。

在每次开发的时候,我们直接在这样的模板上,进行二次开发。

3、规范的工具

针对团队情况的不同,我们可能会有不同的模板仓库,我们这个时候,需要对这些集成的模板仓库进行管理。我们期望的状态,直接通过命令行,一键式生成自己想要的模板。(而不是我每次要进行从某个仓库拉一个项目的模板)

这个规范工具不仅仅可以对模板进行初始化,也能直接进行页面的添加(表单页、列表页、详情页),也会进行一些插件的集成(比如我们针对Stylelint,我们希望直接命令行式直接添加到项目中)。

当然,我们团队中的node工具,肯定不仅仅止于此。

规范的介绍

那么针对一个团队,我们需要从哪些方面对团队进行规范的定义呢?个人认为,规范的推进,是一个长期的事情,我们总会遇到新的场景,在新的场景中处理新的规范问题。

规范的内容

规范的大图如下:

image.png

当然,这仅仅是关于规范的内容的一个抛砖引玉,相关的东西其实更多,更复杂。

比如:埋点规范、监控规范、公用组件库、公用工具库、公用Reset css等等。这些东西需要团队内部进行建设。在这些基础能力建设之上,我们才能进一步的做规范。

规范的模板

规范模板就是我们把相关的规范,都定义下来,直接集成到一个模板仓库中。

给大家一个实例

根目录结构:

image.png

src下的目录结构:

image.png

package.json的自动校验部分:

image.png

工具介绍

image.png

在我们的设想中,我们的工具应该承担三部分的内容:

1、针对一个模板仓库的初始化。

2、针对某个模板的页面进行初始化。

3、给这个项目添加和集成相关的插件。

这里所谓的插件,就是对于一个项目的规范中某一块单独的功能,进行添加。

cli工具原理

原理这一块,需要前端对node做工具有一些基本的认知,我们必须要知道。

发布一个npm包:它的核心就是package.json中的一个mian属性,对应的js文件。对外提供的能力。

发布一个cli工具:它的核心就是package.json中的一个bin属性,需要执行的一个js文件。

1、初始化一个模板。

原理就是我们直接把做好的模板,直接用命令行进行加载。

commander:命令行交互的一个node包。

download-git-repo:对git上的代码进行下载的一个node包。

2、添加一个页面。

原理就是针对我们提前定义好的一些页面,直接进行copy,然后放到我们的项目目录里面。或者用到之前提前定义好的模板,进行文件读取操作,替换相关的内容。

3、添加一个插件

本质就是针对当前仓库,读取仓库内容,添加我们已有的能力。

比如我读取到已经初始化的一个模板中,没有eslint的能力,那么我可以直接在这个模板仓库中,添加一个eslint,这个eslint是我们定义的规范的规则,同时也能在git周期钩子中进行校验代码。

未来展望

我们团队已经做了相当一部分的工作了,包含规范、模板、以及工具层面。但是整个公司的规范体系,是一个循序渐进的过程。我们还有相当多的内容需要集成。

规范方面:

1、针对我们的埋点业务,能够方便前端进行一键式添加埋点的功能。

2、针对监控方面,我们需要统一化的前端监控方案,定义成规范,直接在插件中集成。

3、工具库的建设、工具库的接入等等。

模板方面:

1、已有模板能力的完善。

2、模板类型的扩充(node、小程序等)

3、模板的JSON化能力

工具方面:

1、工具读取json,生成模板的能力。

2、插件能力的支持。

3、插件的扩充。