前端基建任務落到你身上時，該如何推動協作？「實踐」

作者：前端勸退師

轉發連接：https://mp.weixin.qq.com/s/Y0S0X_sx_6IlgXQIDd3DkQ

前言

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

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

話雖如此，經過 4 年生涯摧殘的廢猿我，也是有自己的一番心得體會的。

1. 從DevOps流程看前端基建

很多專注於切圖的萌新前端看到這張圖是蒙圈的：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 三層代碼規範約束

• 第一層，ESLint：

常見的ESLint風格有：airbnb，google，standard。

在多個項目間，規則不應左右橫跳，如果項目週期緊張，可以適當放寬規則，讓warning類弱警告可以通過。且一般建議成員的IDE和插件要統一，將客觀因素影響降到最低。

• 第二層，Git Hooks。

git 自身包含許多 hooks，在 commit，push 等 git 事件前後觸發執行。

而husky能夠防止不規範代碼被commit、push、merge等等。

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

<code>npm 
install
 husky pre-
commit
  /<code>

拿我以前的項目為例子：

<code> 
  
"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" 

    }
  },/<code>

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

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

<code>
## 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'/<code>

• 第三層，CI(持續集成)。

《前端代碼規範最佳實踐》

前兩步的校驗可以手動跳過（找罵），但CI中的校驗是絕對繞不過的，因為它在服務端校驗。使用 gitlab CI 做持續集成，配置文件 .gitlab-ci.yaml 如下所示:

<code>
lint 
:

  
stage
:
lint
  
only
:

    
-/^feature\/.*$/
  
script
:

    
-npmlint
/<code>

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

2. 統一前端物料

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

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

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

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

但是每個新團隊都有自己的 UI 風格取向，你單引一個ElementUI，肯定會出現業務水土不服以及觀感不同的地方，而如果你在每個項目都強行魔改，到處汙染樣式，這得多心累啊。

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

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

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

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

類似於組件庫的官方文檔，卻更加強大。可以通過控件和對出入參數調整，快速查看組件的用法，測試也可以對組件功能完整性等做校驗。

一般的建議步驟是：

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

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

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

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

3. 在團隊外促進協作

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

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

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

首先是原型方面：

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

其次是後端：

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

然後是測試方面：

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

最後是運維方面：

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

3. 效率溝通工具

可能大家比較習慣的是使用QQ或者微信去傳輸文件，日常溝通還行，就是對開發者不太友好。

如何是跨地區溝通，一般都是建議jira+slack的組合，但這兩個工具稍微有些水土不服。

溝通項目管理企業微信Teambition釘釘Tapd

這四個工具隨意選擇都不會有太大問題。

內心 OS: 請在下班後關閉以上工具的消息推送...

結束

搞前端基建這玩意兒，可比寫代碼累多了。。

作者：前端勸退師

轉發連接：https://mp.weixin.qq.com/s/Y0S0X_sx_6IlgXQIDd3DkQ