前端開發上線規範

開發我的項目時，不用準守所謂的開發上線規範，隨意點也無所謂。而在開發公司項目時，咱們不得不爲設立一套規則和流程來進行規範。其目的有三個：

• 用戶可以正常訪問
• 團隊可以協同開發
• 我的可以成長進步

爲此，咱們團隊在逐步的去探索一套，適合咱們的前端開發上線流程。探索的過程從兩方面入手。

• 工程化
• 流程化

工程化

咱們團隊的 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 簡單介紹）：

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 的上線流程。