前端項目如何管理

前端項目的管理分爲兩個維度：項目內的管理與多項目之間的管理。

1. 項目內的管理

在一個項目內，當有多個開發者一塊兒協做開發時，或者功能愈來愈多、項目愈來愈龐大時，保證項目井井有理的進行是至關重要的。

通常會從下面幾點來考證一個項目是否管理得很好：

1. 可擴展性：可以很方便、清晰的擴展一個頁面、組件、模塊

2. 組件化：多個頁面之間共用的大塊代碼能夠獨立成組件，多個頁面、組件之間共用的小塊代碼能夠獨立成公共模塊

3. 可閱讀性：閱讀性良好（包括目錄文件結構、代碼結構），可以很快捷的找到某個頁面、組件的文件，也能快捷的看出項目有哪些頁面、組件

4. 可移植性：可以輕鬆的對項目架構進行升級，或移植某些頁面、組件、模塊到其餘項目

5. 可重構性：對某個頁面、組件、模塊進行重構時，可以保證在重構以後功能不會改變、不會產生新 bug

6. 開發友好：開發者在開發某一個功能時，可以有比較好的體驗（很差的體驗好比：多個文件相隔很遠）

7. 協做性：多人協做時，不多產生代碼衝突、文件覆蓋等問題

8. 可交接性：當有人要離開項目時，交接給其餘人是很方便的

1.1 可擴展性

對於前端項目而言，可擴展性是並不難的，由於不少時候前端的代碼、文件分塊都是按照頁面來的，因此自然就是一塊一塊的。

但這裏仍是要提一下，由於有些開發者不喜歡分塊，把應該分塊的東西雜揉在一塊兒，好比：

- src/
  - main/                    # main 目錄
    - css/                   # css 集合
      - alpha.css
      - beta.css
      - ...
    - js/                    # js 集合
      - alpha.js
      - beta.js
      - ...    
    - alpha.html             # alpha 頁面
    - beta.html              # beta 頁面
    - ...

　　

更好的方式：

- src/
  - main/                    # main 目錄
    - alpha/                 # alpha 頁面
      - index.css            # css 入口文件
      - index.js             # js 入口文件
      - index.html           # html 入口文件
      - ...
    - beta/                  # beta 頁面
      - index.css
      - index.js
      - index.html
      - ...
    - ...
使前端項目具備高可擴展性，通常從目錄文件結構入手。

1.2 組件化
這裏的組件化是項目內的組件化，咱們能夠把多個頁面之間共用的大塊代碼獨立成組件，多個頁面、組件之間共用的小塊代碼獨立成公共模塊。

這樣作的目的是爲了提升代碼的可重用性，避免重複造輪子。另外，也有利於代碼之間的解耦。

好比：

- src/
  - data/                    # 常量、靜態數據目錄
    - data1.js          
    - data2.js
    - ...          
  - components/              # 組件目錄
    - componnet1/          
    - componnet2/
    - ...          
  - utils/                   # 工具函數目錄
    - util1.js          
    - util2.js
    - ...     
  - ...   

　　

1.3 可閱讀性

這裏的可閱讀性有兩個方面：目錄文件結構、代碼結構。

1.3.1 目錄文件結構

目錄文件結構可閱讀性的好與否除了跟開發者有關係外，跟項目的搭建者也有很大的關係，由於若是搭建者在最初就定義好整個項目的目錄結構，對後期的開發者是一個很好的約束。

可閱讀性比較差的目錄文件結構：

- src/
  - css/                     # css 集合
    - main/                  # main 目錄
      - alpha.css
      - beta.css
      - ...
  - js/                      # js 集合
    - main/                  # main 目錄
      - alpha.js
      - beta.js
      - ...
  - html/                    # html 集合
    - main/                  # main 目錄        
      - alpha.html           # alpha 頁面
      - beta.html            # beta 頁面
      - ...
可閱讀性比較好的目錄文件結構：

- src/
  - main/                    # main 目錄
    - alpha/                 # alpha 頁面
      - index.css            # css 入口文件
      - index.js             # js 入口文件
      - index.html           # html 入口文件
      - ...
    - beta/                  # beta 頁面
      - index.css
      - index.js
      - index.html
      - ...
    - ...

　　

1.3.2 代碼結構

代碼結構的可閱讀性大部分取決於開發者的水平，但咱們可使用工具幫助開發者書寫規範、格式良好的代碼。

主要有下面的工具：

1. .editorconfig: 統一每一個開發人員的編輯器配置

2. eslint: 檢查 js 語法（包括 jsx 語法），而後最大程度的矯正不符合規範的代碼

3. stylelint: 檢查 css 語法（包括 less, scss 語法），而後最大程度的矯正不符合規範的代碼

4. prettier: 代碼格式優化

5. husky + lint-staged: 強制開發人員對代碼進行檢查、自動矯正與優化

1.4 可移植性

可能的狀況下，讓項目具備必定的伸縮性，能夠在將來輕鬆的對項目進行架構升級。

讓項目可以輕鬆的移植某些頁面、組件、模塊到其餘項目，須要對整個項目代碼儘可能的解耦與模塊化。另外，也與後面會講到的「項目之間的統一性」有關。

1.5 可重構性

對頁面、組件的重構是常有的事，但怎樣保證在重構以後功能不會改變、不會產生新 bug，這就得靠測試用例了。

• js 模塊：jest / mocha / tape / ava

• React 組件：enzyme + jest，另外可使用 react-testing-library 代替 react-dom/test-utils

• Vue 組件：vue-test-utils + jest / mocha / tape / ava

 

1.6 開發友好

這主要是從目錄結構優化着手，好比：

像下面這種目錄結構，若是要編輯一個頁面，須要處處找頁面相關的文件，編輯器上就會造成一個很長的目錄樹，一點不友好：

- src/
  - css/                     # css 集合
    - main/                  # main 目錄
      - alpha.css
      - beta.css
      - ...        # 中間有 30 個頁面
  - js/                      # js 集合
    - main/                  # main 目錄
      - alpha.js
      - beta.js
      - ...        # 中間有 30 個頁面
  - html/                    # html 集合
    - main/                  # main 目錄        
      - alpha.html           # alpha 頁面
      - beta.html            # beta 頁面
      - ...        # 中間有 30 個頁面
而像下面這種目錄結構，全部的文件都在一個目錄下，找文件就很方便，並且很清晰：

- src/
  - main/                    # main 目錄
    - alpha/                 # alpha 頁面
      - index.css            # css 入口文件
      - index.js             # js 入口文件
      - index.html           # html 入口文件
      - ...
    - beta/                  # beta 頁面
      - index.css
      - index.js
      - index.html
      - ...
    - ...

　　

1.7 協做性

當項目變大、多人協做時，咱們就須要管理好哪些是正在開發的代碼、哪些是提交測試的代碼、哪些是已經上線的代碼、如何避免代碼衝突與線上新代碼被舊代碼覆蓋等等。

1.8 可交接性

當有人要離開項目時，就須要把他負責的代碼交接給別人，但怎麼樣才能使交接是輕鬆愉快的？

那就是文檔，包括註釋文檔、接口文檔等。想一想，若是沒有文檔，該怎樣交接呢？

2. 多項目之間的管理

多個項目之間，如何管理好項目之間聯繫，好比共用組件、公共模塊等，保證快捷高效開發、不重複造輪子，也是很重要的。

通常會從下面幾點來考證多個項目之間是否管理得很好：

1. 組件化：多個項目共用的代碼應當獨立出來，成爲一個單獨的組件項目

2. 版本化：組件項目與應用項目都應當版本化管理，特別是組件項目的版本應當符合 semver 語義化版本規範

3. 統一性：多個項目之間應當使用相同的技術選型、UI 框架、腳手架、開發工具、構建工具、測試庫、目錄規範、代碼規範等，相同功能應指定使用固定某一個庫

4. 文檔化：組件項目必定須要相關的文檔，應用項目在必要的時候也要造成相應的文檔

2.1 組件化

這裏的組件化是項目之間的組件化，咱們能夠把多個項目共用的代碼獨立出來，成爲一個單獨的組件項目。

這樣作的目的也是爲了提升代碼的可重用性，避免重複造輪子。另外，也便於版本化管理組件。

- project1/                  # 項目一
  - package.json
  - src/ 
  - ...
  
- project2/                  # 項目二
  - package.json
  - src/ 
  - ...  
  
- component1/                # 組件一
  - package.json
  - src/ 
  - dist/ 
  - ...
  
- component2/                # 組件二
  - package.json
  - src/ 
  - dist/ 
  - ...    
在 project1 中使用 component一、component2:

# package.json
{
  "dependencies": {
    "component1": "^0.0.1",
    "component2": "^0.0.1"
  }
}

import component1 from 'component1';
import component2 from 'component2';
經常使用組件有：

@yourCompany/utils: 工具類

@yourCompany/shortcut.css: 快捷 css 類

@yourCompany/data: 經常使用靜態數據

...

　　

組件化通常會與私有 npm 倉庫一塊兒使用。

2.2 版本化

若是應用項目使用 npm 來管理依賴，就是版本化管理了。

組件項目更不用說了，值得提一下的是組件項目的版本號應當符合 semver 語義化版本規範。

版本格式：主版本號.次版本號.修訂號，版本號遞增規則以下：

• 主版本號：當你作了不兼容的 API 修改，

• 次版本號：當你作了向下兼容的功能性新增，

• 修訂號：當你作了向下兼容的問題修正。

先行版本號及版本編譯元數據能夠加到「主版本號.次版本號.修訂號」的後面，做爲延伸。

2.3 統一性

多個項目之間應當使用相同的技術選型、UI 框架、腳手架、開發工具、構建工具、測試庫、目錄規範、代碼規範等，相同功能應指定使用固定某一個庫。

這樣作的目的是減小項目之間的環境差別，有利於項目之間的代碼移植，也更有利於組件化、代碼重用。

2.4 文檔化

完善的文檔，不論是對組件項目仍是應用項目，都是很重要的。

組件項目須要用文檔告訴開發者組件怎麼用、有哪些接口；應用項目須要用文檔來作小組交流、項目交接等。