前端團隊如何作規範

背景和設想

任何團隊，規範都是怎麼也繞不開的話題，咱們有太多的理由去作規範，同時咱們在作規範這件事上也有太多的痛點，那麼有沒有這樣的一種方式，讓規範這一件事情既能很好的落實，又對於咱們的研發效能不會有什麼影響？css

任何事情，咱們得知道，到底這件事情的難點在哪裏？

一、針對規範自己而言。前端

規範理解不統一的問題。團隊中的每個人，對規範的理解是不統一的，好比定義一個常量，有些人喜歡用大寫字母，有些人以爲不用糾結這個細節。有時候，你們對規範的邊界理解，也是不統一的，有些人認爲，咱們的規範就是咱們編碼層面的規範，有些人認爲，規範應當還包括工程層面的東西，好比項目的文件目錄結構究竟是怎麼樣的。node

人力成本的問題。咱們定義了規範，咱們須要遵照相關的規範，那人力成本可能就會增長，好比咱們要求代碼結尾須要有分號，有些時候咱們忘了加這個分號，咱們要求要遵循駝峯命名，可是有時候就沒有遵循。因此咱們須要作代碼review。git

落地難的問題。每一個人都有本身的編碼習慣，統一的風格一定會致使團隊內部的差別性。項目週期會有緊有鬆，致使真實落地的時候，就會出現現實與理想的割裂感。npm

二、針對團隊來講json

咱們可能會有這麼一些問題：咱們的團隊技術棧不統一，不少公共的建設無法開展；團隊中沒有完善的文檔建設，你們無法造成一個統一的規範共識；規範落地的過程，難度很大，成本很高；在規範相關的制度上，咱們可能也沒有相關的制度保障。小程序

關於規範，咱們雲積分的設想

如上圖所示markdown

咱們雲積分針對規範，把規範劃分爲三層，分別是規範的定義、規範的模板、規範的工具。工具

一、規範的定義

規範包含的內容，多種多樣，好比有針對GIT的規範、CSS的規範、JS的規範等等。編碼

咱們把這些規範定義下來，直接經過第三方工具，自動化進行代碼的lint校驗、COMMIT Msg校驗等等。

原理是什麼呢？原理就是咱們把這些基礎的規範，在GIT提交的週期鉤子中，先進行校驗經過，經過了以後，才能commit成功。同時咱們提供相關的命令行工具，直接針對咱們不規範的代碼，直接格式化的處理，盡最大的可能性，減小人工在這個過程當中的精力耗費。

二、規範的模板

咱們雲積分是這麼理解規範的，就是所謂的規範，必定是某個項目的規範，咱們須要針對咱們定義的全部規範，直接集成到咱們的項目模板中。

好比在一個Vue的模板倉庫中，咱們針對這個倉庫，集成了GIT COMMIT校驗、ESlint校驗、Stylelint校驗、目錄結構的預約義、相關的公用庫的選擇、本身團隊內部的組件庫、工具庫等等。

在每次開發的時候，咱們直接在這樣的模板上，進行二次開發。

三、規範的工具

針對團隊狀況的不一樣，咱們可能會有不一樣的模板倉庫，咱們這個時候，須要對這些集成的模板倉庫進行管理。咱們指望的狀態，直接經過命令行，一鍵式生成本身想要的模板。（而不是我每次要進行從某個倉庫拉一個項目的模板）

這個規範工具不只僅能夠對模板進行初始化，也能直接進行頁面的添加（表單頁、列表頁、詳情頁），也會進行一些插件的集成（好比咱們針對Stylelint，咱們但願直接命令行式直接添加到項目中）。

固然，咱們團隊中的node工具，確定不只僅止於此。

規範的介紹

那麼針對一個團隊，咱們須要從哪些方面對團隊進行規範的定義呢？我的認爲，規範的推動，是一個長期的事情，咱們總會遇到新的場景，在新的場景中處理新的規範問題。

規範的內容

規範的大圖以下：

固然，這僅僅是關於規範的內容的一個拋磚引玉，相關的東西其實更多，更復雜。

好比：埋點規範、監控規範、公用組件庫、公用工具庫、公用Reset css等等。這些東西須要團隊內部進行建設。在這些基礎能力建設之上，咱們才能進一步的作規範。

規範的模板

規範模板就是咱們把相關的規範，都定義下來，直接集成到一個模板倉庫中。

給你們一個實例

根目錄結構：

src下的目錄結構：

package.json的自動校驗部分：

工具介紹

在咱們的設想中，咱們的工具應該承擔三部分的內容：

一、針對一個模板倉庫的初始化。

二、針對某個模板的頁面進行初始化。

三、給這個項目添加和集成相關的插件。

這裏所謂的插件，就是對於一個項目的規範中某一塊單獨的功能，進行添加。

cli工具原理

原理這一塊，須要前端對node作工具備一些基本的認知，咱們必需要知道。

發佈一個npm包：它的核心就是package.json中的一個mian屬性，對應的js文件。對外提供的能力。

發佈一個cli工具：它的核心就是package.json中的一個bin屬性，須要執行的一個js文件。

一、初始化一個模板。

原理就是咱們直接把作好的模板，直接用命令行進行加載。

commander：命令行交互的一個node包。

download-git-repo：對git上的代碼進行下載的一個node包。

二、添加一個頁面。

原理就是針對咱們提早定義好的一些頁面，直接進行copy，而後放到咱們的項目目錄裏面。或者用到以前提早定義好的模板，進行文件讀取操做，替換相關的內容。

三、添加一個插件

本質就是針對當前倉庫，讀取倉庫內容，添加咱們已有的能力。

好比我讀取到已經初始化的一個模板中，沒有eslint的能力，那麼我能夠直接在這個模板倉庫中，添加一個eslint，這個eslint是咱們定義的規範的規則，同時也能在git週期鉤子中進行校驗代碼。

將來展望

咱們團隊已經作了至關一部分的工做了，包含規範、模板、以及工具層面。可是整個公司的規範體系，是一個按部就班的過程。咱們還有至關多的內容須要集成。

規範方面：

一、針對咱們的埋點業務，可以方便前端進行一鍵式添加埋點的功能。

二、針對監控方面，咱們須要統一化的前端監控方案，定義成規範，直接在插件中集成。

三、工具庫的建設、工具庫的接入等等。

模板方面：

一、已有模板能力的完善。

二、模板類型的擴充（node、小程序等）

三、模板的JSON化能力

工具方面：

一、工具讀取json，生成模板的能力。

二、插件能力的支持。

三、插件的擴充。