工具鏈

這裏有一份簡潔的前端知識體系等待你查收，看看吧，會有驚喜哦~若是以爲不錯，麻煩star哈~

前言

古語云：「工欲善其事，必先利其器」，程序員羣體對工具的愛好和重視是一個悠久的傳統。簡單趁手的工具是程序員開發的好幫手。

可是在工程方面，工具不只僅是簡單的「趁手」便可，假如一個團隊人人都本身發明幾個小工具，那麼後果將會是災難性的：同一個團隊的同窗沒法互相配合寫代碼，一旦有人離職，可能某一個項目就永遠沒法跑起來了。

因此咱們今天從工程的角度談一談工具體系的規劃。

工具總論

跟性能不一樣，工具體系並不是業務結果，因此咱們無法用簡單的數據指標來衡量工具，它的結果更多程度是一種開發體驗：幫助技術團隊內的同窗提高效率和體驗。

做爲工程體系，咱們考慮工具的時候一樣要遵循基本規則：現狀與指標、方案、實施、結果和監控。

不過，對工具而言，指標和結果都是一種「軟性指標」，也就是團隊的開發效率和開發體驗。這裏我不太推薦把開發效率和開發體驗過分數據化，個人經驗是：開發效率提高n倍永遠是一種臆想或者主觀論斷。

工具體系的目標

前面已經講到，工具是爲技術團隊自己服務的工程體系，那麼，工具的目標是什麼呢？其實每一種工具的出現，必然都有一個很是具體的目標，好比npm幫助咱們進行包管理，Yeoman幫助咱們初始化項目模板。

可是這些目標是工具的目標，不是工具體系的目標。咱們作一個假設，假如你是一個前端團隊的工具體系負責人，如今要你來規劃團隊的工具體系，你會怎麼作呢？

若是你到社區找了一大堆工具，而且把它們要解決的問題都羅列出來，做爲工具體系的目標，那就徹底走上了錯誤的道路。

實際上，在考慮具體的工具以前，咱們應該解決工具體系的「元問題」，即：咱們對工具自己的要求是什麼？

考慮到工程行爲都是團隊合做，咱們對工具最基本的要求就是：版本一致。

只有整個團隊的工具版本一致，至少要作到避免大版本差別，才能作到互相接手代碼時，團隊成員可以正確的使用工具開發。

工具體系的另外一個重要需求是：避免衝突，一些工具可能互相沒有干擾，好比Yeoman和gulp，有一些工具則由社區設計了配合方案，好比webpack和babel，有一些工具，則存在着根本性衝突，如gulp和grunt。

因此，在談及具體問題以前，咱們必需要有這兩個要求的解決方案。這就須要引入一個新的概念：工具鏈。

工具鏈是一系列互相配合的工具，可以協做完成開發任務（注：工具鏈這個詞最先是由C/C++程序員引入的概念，通常包含編譯、連接、調試等工具）。

下面咱們就來談談工具鏈的設計。

工具體系的設計

要想設計一個工具鏈，首先咱們須要整理一下，前端開發大約要作哪些事，下面是個人答案：

• 初始化項目；
• 運行和調試；
• 測試（單元測試）；
• 發佈。

那麼，一個前端項目的工具鏈，大約就會包含這些功能。一個典型的社區項目工具鏈可能就相似下面這樣：

• Yeoman
• webpack
• ava/nyc
• aws-cli

可是，這顯然不夠，咱們還須要一種機制，保證團隊使用的工具版本一致。

輕量級的作法是，在項目初始化模板中定義npm script而且在npm dev-dependency中規定它的版本號。

重量級的作法是，開發一個包裝工具，在命令行中不直接使用命令，而使用包裝過的命令。如在我以前的團隊，使用的工具名爲def，它規定了一些命令：

• def init
• def dev
• def test
• def publish

這樣，工具鏈的使用者只需指定工具鏈名稱，就不須要知道項目具體使用了哪些工具，這樣只須要專一本身的需求就夠了。

同時，統一的命令行入口，意味着整個團隊不須要互相學習工具鏈，就能夠接手別人的項目開發。

在稍微大一些的團隊內部，每每會須要不止一種開發模式，如移動開發和桌面開發，這樣，所須要的工具鏈也不同，所以咱們須要多條工具鏈。

要想開發新的工具鏈，可使用複製分支的方式來擴展原來的工具鏈。在我原來的工做中，不一樣的工具鏈被稱做「套件」，每一種套件對應着一組互相配合的工具。

工具體系的執行

由於工具體系服務的是團隊內部成員，因此執行很是簡單，同時，工具體系的入口是初始化項目，因此只要初始化工具在手，能夠控制其它全部工具。

咱們在性能的那一課裏，已經講過工程體系的執行分紅三個層次：純管理、制度化和自動化。

工具體系由於其自身特性，能夠說是最容易作到自動化的一個體繫了。

工具體系的監控

工具體系的結果雖然是軟性的，也不能徹底不作監控。

純粹的社區方案比較難作到監控，可是若是咱們使用了前面提到的統一命令行入口包裝，那麼就能夠作一些簡單的統計工做了。

通常來講，如下指標跟開發者體驗較爲相關：

• 調試/構建次數；
• 構建平均時長；
• 使用的工具版本；
• 發佈次數。

在我以前的工做中，工具團隊曾經從構建平均時長數據中發現構建效率問題，對webpack作了大量深度優化來改善開發體驗。

同時，工具的相關數據還可以幫助發現一些問題，好比某個項目頻繁發佈，可能說明它風險很高。工具的相關數據還能幫咱們發現老舊的工具，若是某個套件使用頻率極低，則能夠考慮把它下線。

總之，工具體系的監控不只僅是衡量工具體系的好幫手，也是很是珍貴的研發數據，裏面有不少可挖掘的價值。

總結

這一課，咱們講解了工具相關的工程知識。

咱們仍然從目標、方案設計、執行和結果四個方面來說解，工具體系的目標除了單個工具解決具體問題以外，還要注意一致性和配合問題，所以咱們須要工具鏈。

工具鏈通常會涵蓋研發階段的各個主要操做。工具體系的執行比較簡單，很容易就能夠作到徹底的自動化。工具體系的監控一樣很是重要，工具的監控除了幫助咱們改進工具體系，對研發體系的其它部分也有幫助。