BACK
前端库 @mini-code 介绍及其协作方式
8 min read
View
前端开发遇到的问题
一些场景
- 新项目启动需要花时间搭建基础框架
- 新人入伍,人员的经历不同,思维不同,人月神话
- 人员的代码风格和质量不一
- 旧模块改动没有测试,容易出错
- 人员变动后对项目的影响
- 人容易健忘,例如忘掉要写注释
- 线上产品版本迭代容易出错
- 产品迭代后通知各方
为了让团队更好协作,需要一套行之有效的技术解决方案
@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)任务跟踪
- 使用 Github 的 issue 功能
- 把任务细分并记录一条 issue
- assign 对应的人员
- 设置该 issue 的 Milestones(里程碑,指期望的完成时间)
- 对应的人员完成任务后,close 对应的 issue
- 质检员检查已经 close 的 issue 的最终准确性,如果通过检测,就打上代指「已检查」的 label
- 否则 reopen 该 issue
开发协作方式
- 项目负责人建立项目,搭建技术脚手架,确定基础开发方式
- 分配对应的开发人员权限
- 对应的开发人员 fork 主项目库到各自的帐号
- 开发功能完成后提交 pull request
- 项目负责人进行 code review
- 发现问题及时反馈对应人员,否则 merge 到主库的特定分支上
- 上线预发布系统进行功能测试跟踪,和运营方商议后,没有问题则发布到正式线上环境上
- 发布新版本,可以支持相关人员协同管理对应项目的资源版本
- 编写开发文档和用户手册
代码质量
需要 3 个约定来确保产品的质量
- 统一的代码风格,统一开发环境,统一编辑器配置,可以在开发过程中,减少很多后续维护的问题
- 编写测试用例,开发完成只是第一步,还需要有完整的测试用例来确保模块改动后的正确性
- 持续集成,编写完测试用例后,更需要一个环境自动编译构建测试用例的正确性
使用的工具
- ESLint,在编辑器中使用提示功能,自觉遵守约定 (阶段一)
- 使用 facebook 的 jest 测试环境
- 持续集成再做考虑,通用库可以使用 travis ci,业务库可能需要搭建内置环境
参考