如何管理好你團隊的前端代碼

前言

隨着移動互聯網技術的發展，前端在整個項目體系建設中扮演的角色，所處的位置也越來越重要。越來越多的項目和系統，對前端開發人員的技能要求也越來越高，同時團隊中前端工程師的人數的日益壯大，每個人代碼風格也不一樣，在協同開發和后續維護過程中，可能會帶來一些問題。假如由你是該團隊負責人，或這說由你來負責前端代碼管理，你會怎么做？

自建Gitlab

代碼就是公司資產。如何管理這筆資產就顯得尤為重要了。自建gitlab是一個很基礎，很有必要的。強烈建議使用Gitlab進行版本管理，自建Gitlab難度並不大，方便管理，包括代碼管理、權限管理、提交日志查詢，以及聯動一些第三方插件。

可能有的公司還在用svn，或者IBM 提供的一些版本管理工具（RTC）。但還是不如gitlab用起來流暢。因此強烈建議Gitlab來代碼管理。

制定代碼開發規范 Code Guide

為什么要有團隊代碼規范？

雖然這些細節是小事，不會有體驗或者性能上的優化，但是卻體現了一個coder和團隊的專業程度 團隊的願景：成為業界卓越的Web團隊！所以不管團隊有多少人，代碼風格都應該師出同門！

以web前端為例，我們看看代碼規范大概會包含哪些方面：

命名規則

• 項目命名
• 目錄/文件夾命名
• JavaScript文件命名
• css（scss，less）文件命名
• html文件命名

HTML文件代碼規范

• 語法（縮進，dom屬性命名規范，單引號雙引號的運用）
• lang屬性
• 字符串編碼
• IE兼容模式
• css引入方式
• JavaScript文件引入順序
• 避免dom標簽嵌套的層級過多

css 文件代碼規范

• 縮進
• 分號
• 空格
• 換行
• 注釋方案
• 命名
• 媒體查詢
• 等等。。。

JavaScript 文件代碼規范

• 縮進、空格、換行、注釋。。。
• 變量命名
• 函數引用
• 數組對象
• ......其他

根據相關方案，制定好如上開發規范即可。這里強烈推薦騰訊的AlloyTeam團隊的以及airbnb團隊的javascript開發規范

Code Guide by @AlloyTeam

Airbnb JavaScript Style Guide

代碼檢查校驗 ESlint

在上一步中，我們談到了參照規范來編寫代碼，可能有時候多多少少還是會忽略或忘記某些規范，比如空格，縮進，變量引用命名等。因此，這里要引入ESlint，客觀層面依照配置文件來檢查我們的代碼是否按照規范開發。

JavaScript 是一個動態的弱類型語言，在開發中比較容易出錯。因為沒有編譯程序，為了尋找 JavaScript 代碼錯誤通常需要在執行過程中不斷調試。像 ESLint 這樣的可以讓程序員在編碼的過程中發現問題而不是在執行的過程中。 ESLint 的初衷是為了讓程序員可以創建自己的檢測規則。ESLint 的所有規則都被設計成可插入的。ESLint 的默認規則與其他的插件並沒有什么區別，規則本身和測試可以依賴於同樣的模式。為了便於人們使用，ESLint 內置了一些規則，當然，你可以在使用過程中自定義規則。 SLint 使用 Node.js 編寫，這樣既可以有一個快速的運行環境的同時也便於安裝。

ESlint優點總結如下：

• 降低低級bug（例如拼寫問題）出現的概率；
• 增加代碼的可維護性，可閱讀性；
• 硬性統一代碼風格，團隊協作起來時更輕松；

ESlint推薦直接配置到腳手架之中，對我們提高代碼的可維護性的幫助會很大。

ESlint中文網鏈接

代碼美化 Prettier

Prettier，顧名思義，pretty的比較級，可以強硬的翻譯為‘更漂亮的’。那到底什么是Prettier呢？從Prettier官網首頁能看到它是什么：

• An opinionated code formatter（一個有態度的代碼格式化工具）
• Supports many languages（支持多種語言）
• Integrates with most editors（集成到絕大多數編輯器）
• Has few options（僅需極少的配置選擇（其他代碼格式化的工具配置選項太多了））

Prettier的安裝和使用都及其簡單:

// with yarn
yarn add prettier --dev --exact
# or globally yarn global add prettier // with npm npm install --save-dev --save-exact prettier # or globally npm install --global prettier 

使用起來也簡單

prettier [opts] [filename ...]

prettier --check "src/**/*.js"

具體可以看看Prettier官網首頁的介紹。

Pre-commit Hook工具之Husky

Husky can prevent bad git commit, git push and more 🐶 woof!

整個是官方對Husky整個工具的解釋。也就是說在你提交代碼前的插入一個鈎子操作，執行整個操作通過后才可以提交代碼，避免一些差的代碼的提交。 因為很多時候，規范擺在那，不一定每個團隊成員每次提交代碼都會執行，因此在提交代碼前插入一個操作（npm run xxx），這樣也是客觀層面對代碼的保護。

現在比較主流的做法就是結合上一步中的prettier一起使用， 假設你已經通過npm/yarn安裝來，那么看看如何使用

// package.json
{
  "lint-staged": { "**/*.{js,ts,tsx,json,jsx,less}": [ "node ./scripts/lint-prettier.js", "git add" ], "**/*.{js,jsx}": "npm run lint-staged:js", "**/*.less": "stylelint --syntax less" }, "husky": { "hooks": { "pre-commit": "npm run lint-staged", "...": "..." } } } 

也就是說，在pre-commit之前，我們先執行npm run lint-staged，而lint-staged也是我們自定義的一個操作，里面包含來兩個命令:

• node ./scripts/lint-prettier.js
• git add

很顯然，lint-prettier.js主要是讀取prettier配置文件，檢查相關規則文件是否有做美化處理。如果沒有，就會給出相關提示：

// lint-prettier.js 部分代碼

      const isPrettier = prettier.check(input, withParserOptions);
      if (!isPrettier) { console.log(files); console.log( `\x1b[31m ${file} is no prettier, please use npm run prettier and git add !\x1b[0m` ); didWarn = true; } 

因此，prettier + Husky 也強烈推薦運用到項目中。

Typecript

這也是老生常談的話題了，作為JavaScript的超級，typescript優點如下：

TypeScript 增加了代碼的可讀性和可維護性

• 類型系統實際上是最好的文檔，大部分的函數看看類型的定義就可以知道如何使用了
• 在編譯階段就發現大部分錯誤，這總比在運行時候出錯好
• 增強了編輯器和 IDE 的功能，包括代碼補全、接口提示、跳轉到定義、重構等

舉個簡單的例子，假如我們代碼規范都遵守了，eslint 檢查也通過了，prettier也執行了。肉眼能做的都做了。在計算 1 + 1的時候還是會出問題。 因為你根本不知道，或者說不確定程序運行的時候1 是字符串還是數字。如果是兩者為number類型，那么1 + 1 = 2。如果有一個是字符串，那么1+1 = ‘11’。

如果項目條件允許，趁早使用typescript。 當然在安裝typescript的時候，注意要安裝相應的檢查插件：

// package.json 

"tslint": "^5.10.0", "tslint-config-prettier": "^1.10.0", "tslint-react": "^3.6.0", // 如果你是react項目 

vue2.x對typescript的支持不太友好，3.0版本后會逐漸改善。 而react則一直對typescript有着完美的結合。

UI單元測試

可能有人覺得，UI單元測試跟代碼規范看起來似乎沒多大關系。 但我始終堅持一點： 好的代碼邏輯一定是可以寫UI單元測試。如果拿到某個組件，寫其相關的單元測試發現沒法進行，或者案例沒法覆蓋全，那么這個組件寫的是有問題。

也就是說，可寫UI單元測試，是高質量的代碼的一個體現之一。 我們在開發組件的時候，都知道要遵循 高內聚，低耦合的理念。你怎么客觀衡量這個理念呢？還是得通過單元測試。

以react 為例，推薦Jest + Enzyme 來寫單元測試。

jest

Jest是 Facebook 的一套開源的 JavaScript 測試框架， 它自動集成了斷言、JSDom、覆蓋率報告等開發者所需要的所有測試工具，是一款幾乎零配置的測試框架。並且它對同樣是 Facebook 的開源前端框架 React 的測試十分友好。

Enzyme

enzyme 來自 airbnb 公司，是一個用於 React 的 JavaScript 測試工具，方便你判斷、操縱和歷遍 React Components 輸出。Enzyme 的 API 通過模仿 jQuery 的 API ，使得 DOM 操作和歷遍很靈活、直觀。Enzyme 兼容所有的主要測試運行器和判斷庫。

同樣，能寫單元測試的代碼，后續維護、重構起來也會更加得心應手。

代碼評審code review

與其說是代碼評審，倒不如說是代碼交流。不同的人對不同的功能首先有着不同的理解。相互交流，取長補短，促進進步。

一般建議以一個迭代，或者一個版本周期為間隔，有組織的做代碼評審（分享）。

結語

本文主要總結了管理好前端代碼需要注意的幾個點：

• 搭建代碼倉庫
• 制定基本代碼編寫規范
• ESlint
• prettier + husky
• typecript + tslint
• UI單元測試
• 代碼評審 code review

這里也是描述只是一個大的方向，沒有具體實施細節。當前各種社區博客也會有比較詳細的實施細節，告訴我們怎么引入ESlint/typecript等等。

同時，結合到具體項目中 ESlint 、prettier、typecript、等選擇幾個適合你們團隊的方案，能全選當然最好。具體情況具體分析。好的代碼就是好的資產，賞心悅目，便於維護。前端的發展日新月異，ESlint 和tslint 有合並的趨勢。我們需要保持時刻關注。學不動也得學。