前端库 @mini-code 介绍及其协作方式

8 min read
# 记录
View

从一个 UI 库说起

前端开发遇到的问题

一些场景

  • 新项目启动需要花时间搭建基础框架
  • 新人入伍,人员的经历不同,思维不同,人月神话
  • 人员的代码风格和质量不一
  • 旧模块改动没有测试,容易出错
  • 人员变动后对项目的影响
  • 人容易健忘,例如忘掉要写注释
  • 线上产品版本迭代容易出错
  • 产品迭代后通知各方

为了让团队更好协作,需要一套行之有效的技术解决方案


@mini-code 前端系列是这些问题的解决方案之一

  • 快速启动新项目
  • 容易把控产品的进度和质量
  • 提升产品迭代的效率
  • 降低新发布版本影响线上产品运营的风险
  • 减少新加入的人员的接入成本
  • 降低开发人员变动的维护成本
  • 快速响应运营策略变化的技术需求

适配多个终端入口

  • 适配多个角色的终端「用户操作,运营管理,系统管理」
  • 适配多个终端入口「PC Web、Mobile Web、Mobile Native」

以及产品迭代交付

  • 资源发布机制
  • 应用版本号变更
  • Native 热更新机制(Bundle)
  • Native APP 更新机制(重新下载)

业务和通用脚手架的关系结构

结构图


@deer-ui 前端系列关系与协作

![前端系列关系与协作](/assets/images/lib-desc/uke-libs-desc.png)

项目库一览


@deer-ui 与角色的协作关系

![@deer-ui 与角色的协作关系](/assets/images/lib-desc/uke-and-role.png)

任务跟踪

  1. 使用 Github 的 issue 功能
  2. 把任务细分并记录一条 issue
  3. assign 对应的人员
  4. 设置该 issue 的 Milestones(里程碑,指期望的完成时间)
  5. 对应的人员完成任务后,close 对应的 issue
  6. 质检员检查已经 close 的 issue 的最终准确性,如果通过检测,就打上代指「已检查」的 label
  7. 否则 reopen 该 issue

开发协作方式

  1. 项目负责人建立项目,搭建技术脚手架,确定基础开发方式
  2. 分配对应的开发人员权限
  3. 对应的开发人员 fork 主项目库到各自的帐号
  4. 开发功能完成后提交 pull request
  5. 项目负责人进行 code review
  6. 发现问题及时反馈对应人员,否则 merge 到主库的特定分支上
  7. 上线预发布系统进行功能测试跟踪,和运营方商议后,没有问题则发布到正式线上环境上
  8. 发布新版本,可以支持相关人员协同管理对应项目的资源版本
  9. 编写开发文档和用户手册

代码质量

需要 3 个约定来确保产品的质量

  1. 统一的代码风格,统一开发环境,统一编辑器配置,可以在开发过程中,减少很多后续维护的问题
  2. 编写测试用例,开发完成只是第一步,还需要有完整的测试用例来确保模块改动后的正确性
  3. 持续集成,编写完测试用例后,更需要一个环境自动编译构建测试用例的正确性

使用的工具

  1. ESLint,在编辑器中使用提示功能,自觉遵守约定 (阶段一)
  2. 使用 facebook 的 jest 测试环境
  3. 持续集成再做考虑,通用库可以使用 travis ci,业务库可能需要搭建内置环境

参考


Table of Contents