當前端基建任務落到你身上，該如何推進協做？

時間 2020-05-04

標籤前端基建任務落到身上如何推進简体版

原文原文鏈接

前言

做爲一名野生的前端開發，自打本猿入行起，就未通過什麼系統的學習，待過的團隊也是大大小小沒個準兒：css

要麼大牛帶隊，可是後端大牛。
要麼臨時湊的團隊，受制於從前，前端不自由。
要麼從0到項目部署，都是爲了敏捷而敏捷，頗不規範。

話雖如此，通過4年生涯摧殘的廢猿我，也是有本身的一番心得體會的。前端

1. 從`DevOps`流程看前端基建

不少專一於切圖的萌新前端看到這張圖是蒙圈的：node

DevOps是什麼？這些工具都是啥？我在哪？nginx

不少前端在接觸到什麼前端工程化，什麼持續構建/集成相關知識時就犯慫。也有以爲這與業務開發無關，沒必要理會。git

可是往長遠想，切圖是不可能一生切圖的，你業務再怎麼厲害，前端代碼再如何牛，沒有了後端運維測試大佬們相助，一個完整的軟件生產週期就無法走完。github

而成爲一名全棧很難，更別說全鏈路開發者了。web

言歸正傳，當你進入一個新團隊，前端從0開始，怎樣從DevOps的角度去提升團隊效能呢？npm

一套簡易的DevOps流程包含了協做、構建、測試、部署、運行。json

而前端常說的開發規範、代碼管理、測試、構建部署以及工程化其實都是在這一整個體系中。後端

固然，中小團隊想玩好DevOps整套流程，須要的時間與研發成本，不比開發項目少。

DevOps核心思想就是：「快速交付價值，靈活響應變化」。其基本原則以下：

高效的協做和溝通；
自動化流程和工具；
快速敏捷的開發；
持續交付和部署；
不斷學習和創新。

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

2. 在團隊內/外促進協做

前端基建協做方面能夠寫的東西太多了，暫且粗略分爲：團隊內與團隊外。

如下多是前端們都能遇到的問題：

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

三層代碼規範約束

第一層，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
複製代碼

這層校驗，通常在稍大點的企業中，會由運維部的配置組完成。

統一前端物料

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

如何快速封裝部門UI組件庫？

首先，得感謝各大UI組件庫的維護者們，給咱們省了很是多的開發成本。

遙想Jquery時代，處處找插件的日子....

可是每一個新團隊都有本身的UI風格取向，你單引一個ElementUI，確定會出現業務水土不服以及觀感不一樣的地方，而若是你在每一個項目都強行魔改，處處污染樣式，這得多心累啊。

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

解決方案之一，就是國外很火的一個開源庫：StoryBook:

Storybook是一個開源工具，用於獨立開發 React、Vue和 Angular的 UI組件。它能有組織和高效地構建UI組件。

Storybook提供了一個沙箱，用於隔離地構建UI組件。

相似於組件庫的官方文檔，卻更增強大。能夠經過控件和對出入參數調整，快速查看組件的用法，測試也能夠對組件功能完整性等作校驗。

通常的建議步驟是：

將業務從公共組件中抽離出來。
在項目中安裝StoryBook(多項目時另起)
按官方文檔標準，建立stories，並設定參數（同時也建議先寫Jest測試腳本），寫上必要的註釋。
爲不一樣組件配置StoryBook控件，最後部署。

如何統一部門所用的工具函數庫和第三方`sdk`

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

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

在團隊外促進協做

核心原則就是：「能用文檔解決的就儘可能別BB。」

雖然說現今前端的地位愈發重要，但咱們常常在項目開發中遇到如下問題：

不一樣的後端接口規範不同，前端須要耗費大量時間去作數據清洗兼容。
前端靜態頁開發完了，後端遲遲不給接口，由於沒有接口文檔，每天都得問。
測試反饋的問題，在原型上沒有體現。

首先是原型方面：

必定要看明白產品給的原型文檔！！！多問多溝通，這過重要了。
好的產品通常都會提供項目流程詳圖，但前端仍是須要基於實際，作一張頁面流程圖。
要產品提供具體字段類型相關定義，否則得和後端扯皮。。。

其次是後端：

執行Restful接口規範，不符合規範的接口駁回。
- 勸退師就經歷過，前東家有個JAVA架構師，連跨域和Restful都不知道，定的規範不成規範，一個簡單查詢接口返回五六級，其美名曰：「結構化數據」。
- 遇到這種沉浸於本身世界不聽勸的後端，我只有一句勸：要麼把他搞走，要麼跑路吧。
必要的接口文檔站點與API測試（如Swagger，Apidoc），不接受文件傳輸形式的接口。
- 早期的聯調都是經過吶喊告知對方接口的標準。剛開始有什麼不清楚的直接問就行了，可是到了後面的時候連寫接口代碼的那我的都忘了這接口怎麼用，維護成本巨高。
- 在沒有接口文檔站點出現前，接口文檔以word文檔出現，輔以postman、http、curl等工具去測試。但仍然不夠直觀，維護起來也難。
- 以web交互爲主的Swagger解決了測試，維護以及實時性的問題。從必定程度上也避免了扯皮問題：只有你後端沒更新文檔，這聯調滯後時間就不應由前端擔起。