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

前言

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

自建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 有合併的趨勢。咱們須要保持時刻關注。學不動也得學。