前端团队工程化记录

[giscafer]

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

主要内容

• 开发流程规范
• 项目管理规范
• 组件化
• 前后端协作
• DevOps

开发流程规范

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

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

• 良好的文档：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：国外比较热门的接口管理工具

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

（2）后端接口规范

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

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

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

orderBeginNum:1,
orderEndNum:222

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

orderNumbers:[1,222]

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

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

（3）接口的单元测试

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

DevOps

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

• 基于 GitLab CI 的前端工程 CI/CD 实践
• CoolQ/DingTalk 实现CI/CD消息推送到群

1.0版本的情况：

Other

前端团队工程化实践（上） PPT

基建规划

（大图）