开发个人项目时,不用准守所谓的开发上线规范,随意点也无所谓。而在开发公司项目时,我们不得不为设立一套规则和流程来进行规范。其目的有三个:
- 用户能够正常访问
- 团队能够协同开发
- 个人能够成长进步
为此,我们团队在逐步的去探索一套,适合我们的前端开发上线流程。探索的过程从两方面入手。
- 工程化
- 流程化
工程化
我们团队的 gitlab 仓库中已经存在近 200 项目,如果各自为政,没有文档、使用不同技术栈、代码风格也不进行代码校验。那么也就只有写这个项目的人才能进行维护了,换一个人肯定是一脸懵逼。为此我们团队在诸多的技术栈中,选择以 react、react-native 和小程序技术为核心,进行项目开发。
进一步地,使用工程化的手段,打造 react、react-native 和小程序的种子工程。新建项目时,所有的项目都是以种子工程为模板,在此之上进行开发。种子工程内,集成各种团队内事先约定的库和工具,这样就统一了团队的使用和核心库和工具。
-
react、react-native 数据管理:
- ✅ redux
- mobx
- graphQL
- react hooks
-
js 代码检查:(Formatting & Code-quality Rules)
-
✅eslint
- ✅ standard 规范(简单) https://standardjs.com/readme...
- airbnb 规范 (严格)
- jslint
-
- ✅ html/css/js/md ... 代码风格:prettier(Only Formatting Rules)
-
git hooks
-
✅ husky
- "pre-commit": "pretty-quick --staged && npx standard --fix"
- .git/hooks/pre-commit
-
-
✅ 编辑器插件(以 VScode 为例)
-
prettier
- "editor.formatOnSave": true,
- "prettier.disableLanguages": ["javascript"] // 暂时没有研究透在 JS 这块 prettier 比 eslint 优势所在,因此只对 html/css 等做 Formatting,JS Formatting 依旧用的是 eslint standard 规范
-
vscode-standardjs
- "standard.autoFixOnSave": true,
- es7-react-js-snippets 代码输入提示
-
示例 WubaRN 种子工程
流程化
流程化是提高产品需求持续迭代效率的关键,其背后的本质是分工。前端开发上线流程只是,信息产品(对应工业产品)生产其中一环。可以从三个维度进行分解:
- 明确产品需求的生产步骤(产品需求拆解)
- 明确步骤边界和相关责任人(团队任务分工)
- 明确责任人需要专注的任务(个人时间安排)
对于产品本身而言,拆解产品需求,分工提高效率。已经是在第一次工业革命时,就已经被发现的客观规律了。
扣针的制造就分成了 18 道工序。在有些工厂里,这 18 道工序分别由 18 个专门的工人负责完成。当然,也有些工厂会让一个工人完成 2~3 道工序。这个工厂每人每天可以制造出 4,800 枚针。如果工人们不是分别专习于一种特殊的业务,而是各自独立工作,那么任何人都不可能在一天之内制造出 20 枚针,甚至 1 枚也制造不出来——《国富论》
对于团队合作而言,存在人与人之间的沟通成本,如果不能明确开发步骤和责任边界,这将是巨大的灾难。
对于个人而言,即便缺失几个环节,只要完成任务,别人看起也是无所谓。但潜在的损失在于,个人状态不一定能始终保持高效,任何关键环节的缺失,可能导致事故。比如,缺乏沙箱验证,导致上线后页面奔溃。
当然,我讲的都没啥用,因为没踩过坑之前,都感觉无所谓。只有自己踩到坑,才会深有体会。
开发流程:
- ✅ github flow(简单) https://guides.github.com/pdf...
- 一句话介绍:任何人不得直接在 master 上推代码,master 的代码只能通过 merge/pull request 其他分支进行合并 。
- github flow 是 github flow /gitlab flow/ git flow 的最小集
- 介绍 https://guides.github.com/int...
- 翻译 https://blog.csdn.net/jeff_li...
- gitlab flow(一般) https://blog.csdn.net/henryhu...
- git flow(复杂) https://gitbook.tw/chapters/g...
参考:隔壁安卓团队流程(安卓分支管理很复杂,用 github flow 简单介绍):
- 从 master 拉取 feature/fix 分支进行开发
- 在分支上进行开发和自测(冒烟测试)
- 提交 merge request
-
告诉审核人 code review
- 简单的 QQ 丢地址
- 复杂的开个会议室,审核
- 审核人 >= 2
- MR 必须有评论 LGTM(look good to me)
- QA 测试通过
-
由合并人,合并代码
- 安卓团队的合并人和审核人一般不是同一个人
上线流程:
- 自测。RD 开发完毕后,通过静态资源或打包平台同步测试环境,并进行自测。
- 提测。RD 通过邮件或其他形式通知 QA 进行验收。
- 测试。QA 在测试环境进行验收。
- 沙箱。QA 将测试环境资源同步沙箱,再在沙箱进行验收。
- 上线。QA 将沙箱环境资源同步上线,最后在线上进行确认。
参考:WubaRN 上线流程规范
团队规划
- 根据前端开发上线规范,产出或完善 react/wuba-rn/小程序相关的种子工程。
- 针对核心项目,关闭所有人直接 push remote master 的权限,开发者都走 github flow 的上线流程。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。