非大厂的我们，如何去卷一套标准的前端团队规范？

声明：文章为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！

前言

大家好，我是易师傅，一个专门搞前端的搬砖师傅 ~

在上一篇文章《非大厂的我们，要如何去搞基建》中主要带领了大家入门了 如何搞基建，以及基建都有什么；

写文章就要踏踏实实，正所谓：大饼画的再多，吃不到也是白瞎，下面正式开始我们的规范篇 ~

一、场景重现

如果 Leader 在某次 Code Review 时，发现你的代码是如下这样子的；

问：如果 Leader 让你优化，你会如何优化呢？

- 你是选择无视他（Leader），还是无视它（Code）？

// 点击定位按钮，获取县市地址方法
const clickDw = function(type) {
    let dz
    // 地址列表
    let dzTable = ['北京市'，'上海市', '广州市', '深圳市']
    if(type === 1 || type === 2 || type === 3) {
	// do something
	return dz
    } else if (type === 4 || type === 5) {
	// do something
	return dz
    } else {
	// default
	return dz
    }
}

咱们可以从这几方面入手：

命名是否规范？

if 判断是否可以简化？

亦或还有其它优化空间？

大家觉得还有其它优化空间吗？

二、团队存在的问题

我相信许多中小型公司都会面临下面几个问题：

1. 老旧业务代码的技术负债：

2. 要研发进度，不要研发质量：

3. 无 GitFlow 协同工作流：

4. 团队更迭文档负债：

5. 后端接口文档的缺失：

6. 沟通少，导致效率低

7. 研发与产品的爱恨情仇：

正是由于这些问题的存在，从而 影响到团队之间的协作，使团队的效率整体降低，严重的甚至会影响团队和谐；

可想而知 牵一发而动全身 究竟有多大力量了吧！

其实作为一名 “优秀” 的程序员，写的代码无论是可读性、可维护性 还是可复用性 都是必不可少的；

那么如何去写 可读性、可维护性、可复用性 的代码呢？

就值得我们每个人深思熟虑了；

接下来我们带着疑问一起进入规范的世界！

三、规范的定义

规范包含的内容有许多，不同公司在针对现有团队所做的规范标准或许会有出入；

但无论是技术栈的统一，还是代码质量的把控，还是 Git 的钩子函数，亦或者团队文档的输出等等，其实都可以归纳至规范的范畴；

所以咱们可以这么定义（仅限笔者理解）：

在日常开发中，任何能 提高代码可维护性、降低代码理解成本、提高代码的容错率 和 提高项目可扩展性 的统一标准，称之为 规范标准；

四、规范的好处

1. 代码的一致性

2. 降低开发成本

3. 提升团队效率

4. 减少沟通成本

5. 有助于自身成长

6. 提高团队和谐（Code Review）

笔者个人见解：养成编写代码规范的习惯，有助于程序员自身的成长；

五、前端规范都有什么？

因为文章主要讲的是与前端相关，所以下面所述主要是前端相关的主题；

关于前端规范，我大致划分出了下列的内容，具体实施还需以自身公司实际情况为准；

下面让我们一起去看看吧！

1. 前端命名规范

命名 有多重要，我相信每位工程师都能明白其中的重要程度；

一个不好的命名，可能就会引起别人的错误理解；

遵循一套严格的命名规范，无论是对自己还是接手的他人，都会大大降低代码的维护成本，所以想要成为一名合格的前端开发，命名规范是必须的；

一些常见的不规范命名：

一些常见好的命名：

驼峰式命名法介绍：

Case 小驼峰式命名法：首字母小写；

文件资源命名：

    usr/dev/document/front-end/project-vue3

变量命名：

常量全部大写，且用下划线来分割单词，eg：MAX_LENGTH = 1

函数：

// 更新数据
function updateData(){
    return {};
}
// 获取用户信息
function getUserInfo{
    return {}
}

css 命名：

.heavy {
  font-weight: 800;
}
.important { 
  color: red; 
}

2. 技术栈规范

问答题，请选出下列合适的答案：

我相信不同的人肯定都有不同的答案，因为在不同的公司技术栈肯定是不一致的，技术栈不仅取决于领导的拍案叫板，也取决于业务的支持，所以会出现同一个业务部门会有不同的技术栈的情况；

我司选择答案：

为什么用 TypeScript 而不用 JavaScript 呢？

为什么用 Vue 而不用 React ？

为什么用 Sass 而不是 Less ？

为什么用 Vite 而不是 Webpack？

注意：使用新技术前要考量其学习成本、带来的收益以及存在的风险等等，切勿盲目追行情。

3. 编程规范

为什么需要编程规范？

实际开发中因为没有规范而导致的问题真的不要太多太多；有因为 JavaScript 不规范的，也有因为 CSS 不规范的；

但是我们究其原因，无非就是没有一个所谓的统一标准而导致；

正所谓：无规矩不成方圆，有了规范才有好的团队~

编程规范的意义：

编程规范都有什么？

怎么搞编程规范？

确定现有团队的问题；

定制属于自己公司的规范（从上面导图入手）；

统一规范应以自动化为前提；

推荐几个编程规范文档

4. Git 规范

为什么要 Git 规范？

在实际开发中，无论是 Git 版本的规范，还是 Git Commit 的规范，都是一环较重要的部分，因为他们绝对是大有裨益的；

如何去做 Git 规范？

Git 版本规范

版本规范其实有许多种工作流形式，有 Git flow，有集中式工作流，有功能分支工作流；

这里主要说一下较为常用的 功能分支流；

功能分支工作流是以集中式工作流为基础的。它提倡为各个新功能分配一个专门的分支来开发， 当功能分支稳定，或者说经过完备的测试之后才合并到 master 分支。

功能分支工作流相较集中式工作流的优点：

Git Commit 规范

(): 
// 注意冒号 : 后有空格
// 如 feat(user): 增加用户中心的 xx 功能

结合工具强制使用 Git Commit 规范：

5. BFF 研发规范

BFF 的设计原则：

前端研发原则：

BFF 是为前端设计的后端，不可图一时之方便而越俎代庖，将大部分本该由后端服务提供的能力据为己有，而更应该关注在前端的体验优化上，做好前后端的隔离，让前后端能够各司其职，合理高效协作。

接口数据返回统一原则

场景：某天 A 同学返回的数据是 msg，但是 B 同学的是 message，所以就会有出入

优化：统一一致的数据格式

微服务接口聚合原则

场景：代码中为了统一成一个接口，BFF 把后端十几个微服务接口聚合成一个，这样对性能有沉重的打击；

优化：秉承五合一原则，即单个接口至多只能聚合五个微服务接口；

业务下沉原则

场景：例如某些需要详细计算的业务逻辑，例如金额的计算等等；

优化：需下沉至后端服务

后端研发原则：

微服务业务单一原则

场景：业务 A 中某个微服务中聚合的业务场景过多，导致对微服务拆分不过细致，对请求效率与维护有一定的影响；

优化：一个业务对应一个微服务

与前端同步原则

场景：某个业务场景中，BFF 需要聚合很多接口，但是 BFF 层前端同学对微服务的业务划分不是很清晰，所以他们在拆分接口时会有些随心所欲，任性聚合；

优化：单个需求业务场景，需与前端同学规划好哪些微服务的接口可以聚合在一起，哪些微服务接口聚合会存在影响；

现在看不懂没关系，详细 BFF 相关文章会在《前端搞基建》专栏中后续输出，敬请期待 ~

6. 前后端协作规范

场景重现：

为什么要前后端协作规范？

随着 前后端分离开发模式 的流行，前端和后端已经在各自领域上渐行渐远；

我们把前后端共同研发的一个需求所产生的关联称之为 联调；

美其名曰联调，如何去把控好这个联调的品质就是我们值得关注的点了 ~

稍不注意就很可能产生不必要的问题。

因此，咱们就很有必要 制定前后端协作规范 来解决这些问题了 ~

前后端协作规范的意义：

前后端协作规范都有什么？

协作规范流程

接口规范

其它规范：

接口文档规范：

注意点：

以上规范摘抄了一些较为通用的部分规范，规范因团队而异 ~

7. UI 设计规范

场景复现：

依稀记得刚进公司时，不同的业务小组弹框右上角的 close 按钮样式大小都不一样；每次要么重写 css ，要么直接重新引入一张新的 close 图，严重影响了大家的开发的效率；

设计规范的意义与目的：

设计规范都有什么？

8. 前端测试规范

为什么前端测试不那么被重视？

就前端而言，前端测试一般可以划分为 针对 UI 的测试，以及面向于组件工具库的测试；

因为所谓「前端」涵盖的领域相对后端形态更加多样化；

归根结底一句话就是：前端页面变化太大，性价比低；

为了提升研发周期，快速迭代相关产品，我相信大部分的企业或开源项目只有在针对组件工具库时才会做 单元测试；

前端测试规范的意义

前端测试的三大类：

集成测试：

UI 测试：

前端测试的常用工具：

9. 浏览器兼容规范

场景复现：

浏览器兼容规范的意义

如何搞浏览器兼容规范？

前端团队应该根据 用户设备类型 、实际开发成本、浏览器市场份额等因素来制定对应的浏览器兼容规范；

从用户设备类型出发：

从浏览器市场份额出发（如图所示）

友情提示：IE 已死，拿着它赶紧去说服你领导吧 ~

10. IDE 编辑器规范

场景复现：

IDE 编辑器规范的意义

前端 IDE 编辑器规范都有什么

11. 需求研发流程规范

为什么需要需求研发流程规范？

讨论题：

这就导致了在没有流程规范前，产品想让你改，你就得去改了；但是有了流程规范呢，那是不是就不一样了，虽然还是会修改需求，但是最起码会有迹可寻；

研发流程规范的意义与目的：

整体的研发流程规范（其中轻化产品部分的流程）：

关于需求变更处理建议：

12. CR 规范（Code Review）

看到这里，其实我们已经制定了一系列的前端规范了；

虽有规范，但是如何去约束到团队的每个成员其实是一个困扰大家的难题；

但是 Code Review 一直都是软件开发中的最佳实践之一，可以有效提高整体代码质量，及时发现代码中可能存在的问题。

像国外的 Google、微软以及国内的大厂等等公司，Code Review 都是基本要求，代码合并之前必须要有人审查通过才行。

Code Review 有什么意义？

搞 Code Review 规范需要注意什么？

如何去做 CR 规范？

好的 Code Review 不仅能提前发现隐藏的 Bug，还能使得团队成员的代码能力得到提高。

相反，不好的 Code Review 带来的不仅不能发现 Bug，不能帮助团队提升，更可怕的是会影响整个团队的开发氛围和团队成员之间的关系。

所以 Code Review 的目的绝不仅仅是发现问题，更重要的是提升团队的开发能力；

六、前端文档都有什么？

相信在座的许多同学都吃过没文档的亏，文档对于企业的团队的发展有多重要，就好比学校里的图书馆；

它无论是对 项目的开发和维护，还是对旧与新的交替，亦或者是团队的建设轨迹，都有着无可代替的作用；

文档有什么作用：

前端文档都有什么？

最后

关于前端规范，在每个企业都会有所差异，受限文章篇幅原因，所以上述主要是介绍了一些常用的规范，我相信你们的团队也一定用的到；

该系列会是一个持续更新系列，关于 前端基建，笔者主要会从如下图几个方面讲解，如果您想第一时间看到我的更新文章，可以关注我和我的《前端要搞基建》专栏

如果你对 Vite 感兴趣，可以看看我的专栏：《Vite 从入门到精通》

如果你对微前端感兴趣，可以看看我的专栏：《微前端从入门到精通》

如果想跟我一起讨论技术吹水， 欢迎加入 前端学习群聊 或加 vx: JeddyGong

感谢大家的支持，码字实在不易，其中如若有错误，望指出，如果您觉得文章不错，记得 点赞关注加收藏 哦 ~