if 我是前端团队 Leader，怎么制定前端协做规范?

万字长文，继续刷新个人文章长度记录，涉及前端开发的方方面面。本文将持续更新和完善, 文章部分观点可能比较武断或不完整，欢迎评论和补充，一块儿完善该文章. 谢谢

笔者长期单枪匹马在前端领域厮杀(言外之意就是团队就一我的)，本身就是规范。随着公司业务的扩展，扩充了一些人员，这时候就要开始考虑协做和编码规范问题了。本文记录了笔者在制定前端协做规范时的一些思考，但愿能给大家也带来一些帮助.

一我的走的更快，一群人能够走得更远，前提是统一的策略，还要不断地检讨和优化。

如下是目录概览, 看出这是一篇浩浩荡荡的长文

1 工做流规范
1.1 开发
1.1.1 版本规范
1.1.2 版本控制系统规范
1.1.3 提交信息规范
1.2 构建规范
1.3 发布工做流规范
1.4 持续集成
1.5 任务管理
2 技术栈规范
2.1 技术选型
2.2 迎接新技术
3 浏览器兼容规范
3.1 肯定兼容策略
3.2 肯定浏览器分级
3.3 获取统计数据
4 项目组织规范
4.1 通用的项目组织规范
4.2 目录组织的风格
4.3 脚手架和项目模板
5 编码规范
5.1 Javascript
5.2 HTML
5.3 CSS
5.4 代码格式化
5.5 集大成的
5.6 特定框架风格指南
5.7 Code Review
6 文档规范
6.1 创建文档中心
6.2 文档格式
6.3 定义文档的模板
6.4 讨论即文档
6.5 注释即文档
6.6 代码即文档
7 UI设计规范
8 测试规范
8.1 测试的流程
8.2 单元测试
9 异常处理、监控和调试规范
9.1 异常处理
9.2 日志
9.3 异常监控
10 先后端协做规范
10.1 协做流程规范
10.2 接口规范
10.3 接口文档规范
10.4 接口测试与模拟
11 培训/知识管理/技术沉淀
11.1 新人培训
11.2 营造技术氛围
12 反馈

CHANGELOG

2019.7.28 新增技术选型
2019.7.29 新增浏览器统计数据获取
2019.9.6 创建技术氛围一节 新增面试题库

什么是规范?

规范，名词意义上：即明文规定或约定俗成的标准，如：道德规范、技术规范等。 动词意义上：是指按照既定标准、规范的要求进行操做，使某一行为或活动达到或超越规定的标准，如：规范管理、规范操做.

为何须要规范?

下降新成员融入团队的成本, 同时也必定程度避免挖坑
提升开发效率、团队协做效率, 下降沟通成本
实现高度统一的代码风格，方便review, 另一方面能够提升项目的可维护性
规范是实现自动化的基础
规范是一个团队知识沉淀的直接输出

规范包含哪些内容?

如文章标题，前端协做规范并不仅仅指‘编码规范’，这个规范涉及到前端开发活动的方方面面，例如代码库的管理、先后端协做、代码规范、兼容性规范；

不只仅是前端团队内部须要协做，一个完整的软件生命周期内，咱们须要和产品/设计、后端(或者原生客户端团队)、测试进行协做, 咱们须要覆盖这些内容.

下面就开始介绍，若是我是前端团队的Leader，我会怎么制定前端规范，这个规范须要包含哪些内容?

1 工做流规范
1.1 开发
1.1.1 版本规范
项目的版本号应该根据某些规则进行迭代, 这里推荐使用语义化版本规范, 经过这个规范，用户能够了解版本变动的影响范围。 规则以下:

主版本号：当你作了不兼容的 API 修改，
次版本号：当你作了向下兼容的功能性新增，
修订号：当你作了向下兼容的问题修正。

⬆️回到顶部

1.1.2 版本控制系统规范
大部分团队都使用git做为版本库，管理好代码也是一种学问。尤为是涉及多人并发协做、须要管理多个软件版本的状况下，定义良好的版本库管理规范，可让大型项目更有组织性，也能够提升成员协做效率.

比较流行的git分支模型/工做流是git-flow, 可是大部分团队会根据本身的状况制定本身的git工做流规范, 例如咱们团队的分支规范

Git 有不少工做流方法论，这些工做流的选择可能依赖于项目的规模、项目的类型以及团队成员的结构.

好比一个简单的我的项目可能不须要复杂的分支划分，咱们的变动都是直接提交到 master 分支;

再好比开源项目，除了核心团队成员，其余贡献者是没有提交的权限的，并且咱们也须要必定的手段来验证和讨论贡献的代码是否合理。 因此对于开源项目 fork 工做流更为适合.

了解常见的工做流有利于组织或建立适合本身团队的工做流, 提交团队协做的效率:

简单的集中式基于功能分支的工做流Git Flow