前端开发上线规范
开发个人项目时，不用准守所谓的开发上线规范，随意点也无所谓。而在开发公司项目时，我们不得不为设立一套规则和流程来进行规范。其目的有三个：
- 用户能够正常访问
- 团队能够协同开发
- 个人能够成长进步
为此，我们团队在逐步的去探索一套，适合我们的前端开发上线流程。探索的过程从两方面入手。
- 工程化
- 流程化
工程化
我们团队的 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 的上线流程。