從DevOps流程看前端基建

　　很多前端在接觸到什麼前端工程化，什麼持續構建/整合相關知識時就犯慫。也有覺得這與業務開發無關，不必理會。但是往長遠想，你業務再怎麼厲害，前端程式碼再如何牛，沒有了後端運維測試大佬們相助，一個完整的軟體生產週期就沒法走完。而成為一名全棧很難，更別說全鏈路開發者了。言歸正傳，當你進入一個新團隊，前端從 0 開始，怎樣從DevOps的角度去提高團隊效能呢？

　　一套簡易的DevOps流程包含了協作、構建、測試、部署、執行。而前端常說的開發規範、程式碼管理、測試、構建部署以及工程化其實都是在這一整個體系中。

　　DevOps核心思想就是：“快速交付價值，靈活響應變化”

• 高效的協作和溝通；

• 自動化流程和工具；

• 快速敏捷的開發；

• 持續交付和部署；

• 不斷學習和創新。

　　接下來我將從協作、構建、測試、部署、運行五個方面談談，如何快速打造用於中小團隊的前端基建。

一、團隊內外促進協作

　　前端基建協作方面可以寫的東西太多了，暫且粗略分為：團隊內 與 團隊外。

　　以下可能是前端們都能遇到的問題：

• 成員間水平各異，編寫程式碼的風格各不相同，專案間難以統一管理。
• 不同專案Webpack配置差異過大，基礎工具函式庫和請求封裝不一樣。
• 專案結構與技術棧上下橫跳，明明是同一 UI 風格，基礎元件沒法複用，全靠複製貼上。
• 程式碼沒註釋，專案沒文件，新人難以接手，舊專案無法維護。

1、三層程式碼規範約束

　　第一層：ESlint

　　常見的ESLint風格有：airbnb，google，standard。在多個專案間，規則不應左右橫跳，如果專案週期緊張，可以適當放寬規則，讓warning類弱警告可以通過。且一般建議成員的IDE和外掛要統一，將客觀因素影響降到最低。

　　第二層，Git Hooks

　　git自身包含許多hooks，在commit，push等git事件前後觸發執行。而 husky 能夠防止不規範程式碼被 commit、push、merge 等等。

　　程式碼提交不規範，全組部署兩行淚。

npm install husky pre-commit  --save-dev
 

　　拿個以前的例子

// package.json
  "scripts": {
    // ...
    "lint": "node_modules/.bin/eslint '**/*.{js,jsx}' && node_modules/.bin/stylelint '**/*.{css,scss}'",
    "lint:fix": "node_modules/.bin/eslint '**/*.{js,jsx}' --fix && node_modules/.bin/stylelint '**/*.{css,scss}' --fix"
  },
  "husky": {
    "hooks": {
      "pre-commit": "npm run lint",
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  },

　　通過簡單的安裝配置，無論你通過命令列還是Sourcetree提交程式碼，都需要通過嚴格的校驗。

　　建議在根目錄README.md註明提交規範：

## Git 規範

使用 [commitlint](https://github.com/conventional-changelog/commitlint) 工具，常用有以下幾種型別：

- feat ：新功能
- fix ：修復 bug
- chore ：對構建或者輔助工具的更改
- refactor ：既不是修復 bug 也不是新增新功能的程式碼更改
- style ：不影響程式碼含義的更改 (例如空格、格式化、少了分號)
- docs ：只是文件的更改
- perf ：提高效能的程式碼更改
- revert ：撤回提交
- test ：新增或修正測試

舉例
git commit -m 'feat: add list'

　　第三層，CI(持續整合)

　　前兩步的校驗可以手動跳過，但CI中的校驗是絕對繞不過的，因為它在服務端校驗。使用gitlab CI做持續整合，配置檔案.gitlab-ci.yaml如下所示：這層校驗，一般在稍大點的企業中，會由運維部的配置組完成。

lint:
  stage:lint
  only:
    -/^feature\/.*$/
  script:
    -npmlint

2、統一前端物料

　　公共元件、公共 UI、工具函式庫、第三方 sdk 等該如何規範？

（1）如何快速封裝部門 UI 元件庫？

　　首先，得感謝各大 UI 元件庫的維護者們，給我們省了非常多的開發成本。遙想Jquery時代，到處找外掛的日子，但是每個新團隊都有自己的 UI 風格取向，你單引一個ElementUI，肯定會出現業務水土不服以及觀感不同的地方，而如果你在每個專案都強行魔改，到處汙染樣式，這得多心累啊。

　　雖然各大元件庫都有提供初始化變數的方式，但業務向的元件就沒辦法了。

　　解決方案之一，就是國外很火的一個開源庫：StoryBook。Storybook是一個開源工具，用於獨立開發React、Vue和Angular的UI元件。它能有組織和高效地構建 UI 元件。Storybook提供了一個沙箱，用於隔離地構建 UI 元件。類似於元件庫的官方文件，卻更加強大。可以通過控制元件和對出入引數調整，快速檢視元件的用法，測試也可以對元件功能完整性等做校驗。

　　一般的建議步驟是：

1. 將業務從公共元件中抽離出來。
2. 在專案中安裝StoryBook(多專案時另起)
3. 按官方文件標準，建立stories，並設定引數（同時也建議先寫Jest測試指令碼），寫上必要的註釋。
4. 為不同元件配置StoryBook控制元件，最後部署。

（2）如何統一部門所用的工具函式庫和第三方sdk

　　其實這裡更多的是溝通的問題，首先需要明確的幾點：

• 部門內對約定俗成的工具庫要有提前溝通，不能這頭裝一個MomentJs，另一頭又裝了DayJS。一般的原則是：輕量的自己寫，超過可接受大小的找替代，譬如:DayJS替代MomentJs，ImmerJS替代immutableJS等。
• 部門間的有登入機制，請求庫封裝協議等。如果是SSO/掃碼登入等，就協定只用一套，不允許後端隨意變動。如果是請求庫封裝，就必須要後端統一Restful風格，相信我，不用Restful規範的團隊都是災難。前端連調會生不如死。
• Mock方式、路由管理以及樣式寫法也應當統一。

二、團隊外促進協作

　　核心原則就是：“能用文件解決的就儘量別 BB。”

　　雖說現今前端的地位愈發重要，但我們經常在專案開發中遇到以下問題：

• 不同的後端介面規範不一樣，前端需要耗費大量時間去做資料清洗相容。
• 前端靜態頁開發完了，後端遲遲不給介面，因為沒有介面文件，天天都得問。
• 測試反饋的問題，在原型上沒有體現。

　　首先是原型方面：

1. 一定要看明白產品給的原型文件！！！多問多溝通，這太重要了。
2. 好的產品一般都會提供專案流程詳圖，但前端還是需要基於實際，做一張頁面流程圖。
3. 要產品提供具體欄位型別相關定義，不然得和後端扯皮。。。

　　其次是後端：

1. 執行Restful介面規範，不符合規範的介面駁回。比如定的規範不成規範，一個簡單查詢介面返回五六級，其美名曰：“結構化資料”。遇到這種沉浸於自己世界不聽勸的後端，我只有一句勸：拒絕。
2. 必要的介面文件站點與 API 測試（如Swagger，Apidoc），不接受檔案傳輸形式的介面。早期的聯調都是通過吶喊告知對方介面的標準。剛開始有什麼不清楚的直接問就好了，但是到了後面的時候連寫介面程式碼的那個人都忘了這介面怎麼用，維護成本巨高。在沒有介面文件站點出現前，介面文件以word文件出現，輔以postman、http、curl等工具去測試。但仍然不夠直觀，維護起來也難。以 web 互動為主的 Swagger 解決了測試，維護以及實時性的問題。從一定程度上也避免了扯皮問題：只有你後端沒更新文件，這聯調滯後時間就不該由前端擔起。

　　然後是測試方面：

1. 為了避免測試提出一些無效的 bug，最好提前參與測試的用例評審。
2. 在實際開發中，如果有不合理功能需要修改，所有的修改都必須要求產品經理更新到 PRD 以及原型設計中。否則，測試如果不知道的話，會認為是 bug。
3. 通過自測和編寫Jest單元測試，將程式碼意外bug降到合理程度。

　　最後是運維方面：

1. 除了CI/CD相關的，其實很可以和運維一起寫寫nginx和外掛開發。