前端团队工程化记录

前端团队工程化记录

记录一些实践内容,给想学习的同学参考

主要内容

开发流程规范

一个高效和实用的开发流程规范,可以被用到各种软件开发项目中,并且使用开源工具来协助和自动化大部分任务。关注基本的开发流程规范,有助于开发过程顺利和提高代码质量。

开发流程基本规范内容有:

  • 良好的文档:README、文档页面、变更日志
  • 良好的编码规范
  • 版本管理
  • 自动化测试:不需要太多,专注在功能性非回归测试就好
  • 开发者体验

良好的文档

此部分可以参考文章 一个靠谱的前端开源项目需要什么? 的描述,变更日志见下边章节 Git 提交规范

Git 提交规范

内容多,单独文章:Git 信息提交规范实践

代码规范与质量

(1)代码检查工具

团队人员水平不一,或者编码习惯不一致,无规范的情况一定是最开心的啦,人人都可以做到 code with fun 了。但是,实际情况不是这样的,你会看到的是乱七八糟的代码表现,每个人的习惯造成各种代码风格,JS 原本就很灵活,100 人可以有 100 种写法。所以,只有制定并强制执行代码规范,项目的代码质量才有所保证。

代码规范包含语法规则和代码风格等,检查工具 ES6 的话用 ESLint,TypeScript 的话用 TSLint。根据前端工程项目的不同,还有对应的规则模块可以配置,建议优先使用网上流行的大厂规范,如 Google 、Airbnb 等,也有一些标准规范,团队规范建设过程中,可以调整细节,形成自己的一套适合团队的代码规范检查规则。这里有个 RN APP 开发的 ESLint 代码检查配置:React Native ESLint Config,目前其实很多前端库/框架的脚手架已自带代码检查配置生成,这种就比较方便了(如 React \Angular\Vue )。相关的配置对应官方文档和网上资料也很多,不详细介绍。

(2)格式化插件/工具

IDE 中有很多格式化插件,团队协作的话,建议使用统一的格式化插件,然后自定义统一的格式化配置文件,比如 VSCode 编辑器常用的格式化扩展程序 Prettier - Code formatter,通过自定义 .prettierrc 插件格式化配置可以保证同一个工程下,所有同学的格式化风格一致。

然后再配合 husky 做 git 的 pre-commit 时做格式化操作和代码规范校验。保证代码提交前,自动做好代码格式化且代码规范校验通过的。相关文章见 Git 信息提交规范实践

(3)总结

代码规范检查工具优点:

  • 统一团队成员的代码书写风格习惯和语法特性规则
  • 保证代码可 Review,友好的 Code Review 体验
  • 自动化过程,减少沟通成本
  • 保证代码质量,降低代码维护成本,减少 bug 风险
  • 团队成员代码质量和编码能力提升

代码分支及版本管理规范

(1)Git 是最好的选择

基于 Git 的简单实用的版本管理规范及流程,包括:代码库的分布、人员角色的划分、代码提交合并流程、代码冲突处理、分支管理。2017 年刚进公司的时候,使用的还是 SVN,年底的时候改用 Git,自搭 Gitlab 作为内部的 git 服务器。

因为常使用 Github,对 Git 相对熟悉一些。所以当时有幸有机会作为分享者去给大部门分享 Git 的基本使用技巧,以及协助公司私服搭建的 Gitlab 落实使用和建设支持。

公司从 SVN 转为 Git 时整理的学习资源:Git 教程指南

(2)代码分支和版本管理

内容多,单独文章:代码分支和版本管理

项目管理规范

项目流程规范

项目流程规范,是为了保证项目正常进行,并控制好质量和风险,更多的是管理好项目成员之间的相互协作。规范是死的,人是活的,很多时候也需要灵活的去协调,并在实践后不断地完善这个流程。 下图是公司团队的一个项目经理绘制的,拿过来用,作为一个演示说明:

敏捷迭代

(待整理)

组件化

(待整理)

前后端协作

在前后端完全分离开发的项目环境下,影响到开发效率最多的情况是在接口对接阶段。后端交付接口的方式,以及接口文档可能存在经常性变动,或者是交付的接口质量,都会直接影响到前端开发人员接口联调对接的效率。所以我们需要从这以下几个主要的地方去解决问题。

一个项目或者需求,前后端开发协作的顺序:后端设计确定表结构 ——> 后端输出接口文档(确定入参、出参) ——> 后端进行接口开发/前端编写并基于mock开发 (并行开发,互不影响) ——> 联调验证接口,交付测试

(1)后端交付接口的方式

前后端分离后,前端为了高效开发,减少后期对接真实接口和环境的工作内容和时间,一般采用 Mock 的方式模拟数据接口,在写页面的时候,就绑定好对应字段和把一些能写的逻辑都写好。在接口不复杂和 Mock 数据结构字段符合的时候,完美的情况,前端在写好页面的时候,就已经对接好了,最后后端接口可行的时候,只需要联通验证即可。 前端在写 Mock 数据的时候,后端需要提供接口的数据结构,所以需要有一个接口文档给到前端,接口文档可以是一些 api 接口和文档管理工具常用的有以下几种。

比较热门的线上工具有:

  • eolinker
  • apizza:界面与 postman 比较像
  • easyapi
  • apiview

企业一般都采用自建 API 接口管理工具,比较热门的有:

  • yapi:去哪儿出品,线上演示地址 http://yapi.demo.qunar.com
  • RAP / rap2-delos + rap2-dolores:阿里出品,线上演示地址 http://rap2.taobao.org/
  • easy-mock:线上演示地址 https://easy-mock.com/
  • swagger:国外比较热门的接口管理工具

公司内部使用过的有 swaggeryapi ,个人感受来讲,yapi 在使用体验和功能上比 swagger 好很多。

(2)后端接口规范

后端开发人员很多,如果没有制定对应的规范,导致的问题将是不同后端开发人员的习惯不同,背景不同,会有不同的接口风格。比如以下情况:

前端页面查询条件是一个区间:

后端开发人员,不同的人就有不同的想法了,有的人是定义两个字段来接受参数:

orderBeginNum:1,
orderEndNum:222

有的则是用数组来接收参数:

orderNumbers:[1,222]

同样的情况在前端组件选择 date range 日期区间作为查询条件也是,我见过有定义两个参数的,有定义为一个数组字符串的。这在前端页面开发的时候,可能造成过多余的数组格式转换,如果同一个项目,不同的后端,有不同的风格,那就惨不忍睹了。很多参数格式可以在组件封装的时候统一确定好的,不需要额外的转换格式。所以,对于后端接口参数格式,不管是入参和出参,有一个统一的格式规范是很有必要的。

另外,还有编辑接口的规范,不同背景后端开发人员养成的习惯不一样,有些开发人员认为表单编辑,前端这边编辑修改了什么内容,接口就传什么内容,没有修改过的东西不要传给接口。而有些开发人员和前面说的不同,把所有表单数据都给接口,接口会都 update 数据。这里不同的要求,对于前端会产生不一样的工作量。所以需要统一一种约定,保证接口约定风格和习惯统一。当然,也有特殊的情况,那些情况可以特殊处理。

(3)接口的单元测试

我认为一些重要和关键的接口编写单元测试是很有必要的,不写测试的项目就是耍流氓。没有单元测试,你无法保证某部分代码是否正常,每次都让 QA 去回归?没有测试,在 CI/CD 过程,也不能做到验证。很多后端开发人员会以没有时间为借口,或者是认为没有必要,觉得 Postman 简单请求两下就 OK 了,剩下丢给前端对接的时候帮忙做测试。我觉得,一旦开发人员习惯写测试,写多了,代码质量和单元测试写的速度都会得到较大的提升,并且很多协助编写单元测试的框架和工具,以及 mock 工具等,利用起来,写测试就不会那么困难了吧。

DevOps

从频繁提交代码、自动化测试(保证测试覆盖) -> 运行本地测试 -> 服务器运行测试 -> 部署到测试环境 -> 交付管理,这些都应该是自动的。CI/CD 可以释放我们的双手,一劳永逸,节约时间和提供效率,本人在公司内部对前端团队的实践部分总结如下:

1.0版本的情况: TIM截图20190626193814

Other

前端团队工程化实践(上) PPT

基建规划

(大图)

Yzt FE Team  前端基础设施建设规划


欢迎前往原文讨论:https://github.com/giscafer/blog/issues/26

相关文章