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

笔者长期单枪匹马在前端领域厮杀(言外之意就是团队就一个人),自己就是规范。随着公司业务的扩展,扩充了一些人员,这时候就要开始考虑协作和编码规范问题了。本文记录了笔者在制定前端协作规范时的一些思考,希望能给你们也带来一些帮助。

一个人走的更快,一群人可以走得更远,前提是统一的策略,还要不断地反省和优化

什么是规范?

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

为什么需要规范?

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

规范包含哪些内容?

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

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

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

1 工作流规范

1.1 开发

1.1.1 版本规范

项目的版本号应该根据某些规则进行迭代, 这里推荐使用语义化版本规范, 通过这个规范,用户可以了解版本变更的影响范围。 规则如下:

  • 主版本号:当你做了不兼容的 API 修改,
  • 次版本号:当你做了向下兼容的功能性新增,
  • 修订号:当你做了向下兼容的问题修正。

1.1.2 版本控制系统规范

大部分团队都使用git作为版本库,管理好代码也是一种学问。尤其是涉及多人并发协作、需要管理多个软件版本的情况下,定义良好的版本库管理规范,可以让大型项目更有组织性,也可以提高成员协作效率。

比较流行的git分支模型/工作流是git-flow, 但是大部分团队会根据自己的情况制定自己的git工作流规范, 例如我们团队的分支规范

Git 有很多工作流方法论,这些工作流的选择可能依赖于项目的规模、项目的类型以及团队成员的结构

比如一个简单的个人项目可能不需要复杂的分支划分,我们的变更都是直接提交到 master 分支;

再比如开源项目,除了核心团队成员,其他贡献者是没有提交的权限的,而且我们也需要一定的手段来验证和讨论贡献的代码是否合理。 所以对于开源项目 fork 工作流更为适合。

了解常见的工作流有利于组织或创建适合自己团队的工作流, 提交团队协作的效率:

粘贴图片

1.1.3 提交信息规范

粘贴图片

组织好的提交信息, 可以提高项目的整体质量. 至少具有下面这些优点:

  • 格式统一的提交信息有助于自动化生成CHANGELOG
  • 版本库不只是存放代码的仓库, 它记录项目的开发日志, 它应该要清晰表达这次提交的做了什么. 这些记录应该可以帮助后来者快速地学习和回顾代码, 也应该方便其他协作者review你的代码
  • 规范化提交信息可以促进提交者提交有意义的、粒度合适的'提交'. 提交者要想好要怎么描述这个提交,这样被动促进了他们去把控提交的粒度

社区上比较流行的提交信息规范是Angular的提交信息规范, 除此之外,这些也很不错:

另外这些工具可以帮助你检验提交信息, 以及生成CHANGELOG:

1.2 构建规范

对于团队、或者需要维护多个项目场景,统一的构建工具链很重要, 这套工具应该强调"约定大于配置",让开发者更专注于业务的开发。笔者在<为什么要用vue-cli3?>文章中提出了vue-cli3更新有很多亮点,非常适合作为团队构建工具链的基础:

  • 首先这类工具是推崇'约定大于配置'。即按照他们的规范,可以实现开箱即用,快速开发业务. 在团队协作中这点很重要,我们不推荐团队成员去关心又臭又长的webpack构建配置
  • vue-cli3抽离了cli service层,可以独立更新工具链。也就是说项目的构建脚本和配置在一个独立的service项目中维护,而不是像以前一样在每个项目目录下都有webpack配置和依赖. 这样做的好处是独立地、简单地升级整个构建链
  • 灵活的插件机制。对于团队的定制化构建应该封装到插件中,这样也可以实现独立的更新。

我们可以选择第三方CLI, 当然也定制自己的构建链,按照上面说的这个构建链应该有以下特点:

  • 强约定,体现团队的规范。首先它应该避免团队成员去关心或更改构建的配置细节,暴露最小化的配置接口。 另外构建工具不仅仅是构建,通常它还会集成代码检查、测试等功能
  • 方便升级。尤其是团队需要维护多个项目场景, 这一点很有意义

下面是社区上比较流行的构建工具. 当然,你也可以根据自己的团队情况开发自己的CLI, 但是下面的工具依然很有_参考价值_:

  • create-react-app - 🔥零配置开始React开发
  • vue-cli - 🔥零配置、渐进增强的项目构建CLI
  • parcel - 零配置的Web应用打包工具
  • Fusebox - 高速易用的打包工具
  • microbundle - 零配置, 基于Rollup,适合用于打包‘库’

1.3 发布工作流规范

发布工作流指的是将‘软件成品’对外发布(如测试或生产)的一套流程, 将这套流程规范化后,可以实现自动化。

举个例子, 一个典型的发布工作流如下:

粘贴图片

  • 代码变更
  • 提交代码变更到远程版本库
  • 程序通过CI测试(例如Travis变绿)
  • 提升package.json中的版本
  • 生成CHANGELOG
  • 提交package.json和CHANGELOG.md文件
  • 打上Tag
  • 推送

如果你遵循上面的规范,那么就可以利用社区上现有的工具来自动化这个流程. 这些工具有:

0 条评论
作者
状态
  • 发布于 ,1 次更新
  • 最后更新于
  • 被浏览 195 次
  • 被评论 0 次
  • 隶属于 文章 版块
  • 归纳于 前端架构 分类
二维码
目录