前端开发上线规范

开发个人项目时，不用准守所谓的开发上线规范，随意点也无所谓。而在开发公司项目时，我们不得不为设立一套规则和流程来进行规范。其目的有三个：

• 用户能够正常访问
• 团队能够协同开发
• 个人能够成长进步

为此，我们团队在逐步的去探索一套，适合我们的前端开发上线流程。探索的过程从两方面入手。

• 工程化
• 流程化

工程化

我们团队的 gitlab 仓库中已经存在近 200 项目，如果各自为政，没有文档、使用不同技术栈、代码风格也不进行代码校验。那么也就只有写这个项目的人才能进行维护了，换一个人肯定是一脸懵逼。为此我们团队在诸多的技术栈中，选择以 react、react-native 和小程序技术为核心，进行项目开发。

进一步地，使用工程化的手段，打造 react、react-native 和小程序的种子工程。新建项目时，所有的项目都是以种子工程为模板，在此之上进行开发。种子工程内，集成各种团队内事先约定的库和工具，这样就统一了团队的使用和核心库和工具。

• react、react-native 数据管理：
• ✅ redux
• mobx
• graphQL

• 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 简单介绍）：

1. 从 master 拉取 feature/fix 分支进行开发
2. 在分支上进行开发和自测(冒烟测试)
3. 提交 merge request

4. 告诉审核人 code review

   • 简单的 QQ 丢地址
   • 复杂的开个会议室，审核
   • 审核人 >= 2
   • MR 必须有评论 LGTM(look good to me)
5. QA 测试通过

6. 由合并人，合并代码

   • 安卓团队的合并人和审核人一般不是同一个人

上线流程：

1. 自测。RD 开发完毕后，通过静态资源或打包平台同步测试环境，并进行自测。
2. 提测。RD 通过邮件或其他形式通知 QA 进行验收。
3. 测试。QA 在测试环境进行验收。
4. 沙箱。QA 将测试环境资源同步沙箱，再在沙箱进行验收。
5. 上线。QA 将沙箱环境资源同步上线，最后在线上进行确认。

参考：WubaRN 上线流程规范

团队规划

1. 根据前端开发上线规范，产出或完善 react/wuba-rn/ 小程序相关的种子工程。
2. 针对核心项目，关闭所有人直接 push remote master 的权限，开发者都走 github flow 的上线流程。