摘要：前端項(xiàng)目如何管理前端項(xiàng)目的管理分為兩個(gè)維度項(xiàng)目?jī)?nèi)的管理與多項(xiàng)目之間的管理。具體可以參考項(xiàng)目如何進(jìn)行多人協(xié)作開發(fā)。組件項(xiàng)目更不用說了，值得提一下的是組件項(xiàng)目的版本號(hào)應(yīng)當(dāng)符合語義化版本規(guī)范。

前端項(xiàng)目的管理分為兩個(gè)維度：項(xiàng)目?jī)?nèi)的管理與多項(xiàng)目之間的管理。

在一個(gè)項(xiàng)目?jī)?nèi)，當(dāng)有多個(gè)開發(fā)者一起協(xié)作開發(fā)時(shí)，或者功能越來越多、項(xiàng)目越來越龐大時(shí)，保證項(xiàng)目井然有序的進(jìn)行是相當(dāng)重要的。

一般會(huì)從下面幾點(diǎn)來考證一個(gè)項(xiàng)目是否管理得很好：

可擴(kuò)展性：能夠很方便、清晰的擴(kuò)展一個(gè)頁面、組件、模塊

組件化：多個(gè)頁面之間共用的大塊代碼可以獨(dú)立成組件，多個(gè)頁面、組件之間共用的小塊代碼可以獨(dú)立成公共模塊

可閱讀性：閱讀性良好（包括目錄文件結(jié)構(gòu)、代碼結(jié)構(gòu)），能夠很快捷的找到某個(gè)頁面、組件的文件，也能快捷的看出項(xiàng)目有哪些頁面、組件

可移植性：能夠輕松的對(duì)項(xiàng)目架構(gòu)進(jìn)行升級(jí)，或移植某些頁面、組件、模塊到其他項(xiàng)目

可重構(gòu)性：對(duì)某個(gè)頁面、組件、模塊進(jìn)行重構(gòu)時(shí)，能夠保證在重構(gòu)之后功能不會(huì)改變、不會(huì)產(chǎn)生新 bug

開發(fā)友好：開發(fā)者在開發(fā)某一個(gè)功能時(shí)，能夠有比較好的體驗(yàn)（不好的體驗(yàn)比如：多個(gè)文件相隔很遠(yuǎn)）

協(xié)作性：多人協(xié)作時(shí)，很少產(chǎn)生代碼沖突、文件覆蓋等問題

可交接性：當(dāng)有人要離開項(xiàng)目時(shí)，交接給其他人是很方便的

對(duì)于前端項(xiàng)目而言，可擴(kuò)展性是并不難的，因?yàn)楹芏鄷r(shí)候前端的代碼、文件分塊都是按照頁面來的，所以天然就是一塊一塊的。

但這里還是要提一下，因?yàn)橛行╅_發(fā)者不喜歡分塊，把應(yīng)該分塊的東西雜揉在一起，比如：

- 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
      - ...
    - ...

使前端項(xiàng)目具有高可擴(kuò)展性，一般從目錄文件結(jié)構(gòu)入手，可以參考：目錄結(jié)構(gòu)優(yōu)化。

這里的組件化是項(xiàng)目?jī)?nèi)的組件化，我們可以把多個(gè)頁面之間共用的大塊代碼獨(dú)立成組件，多個(gè)頁面、組件之間共用的小塊代碼獨(dú)立成公共模塊。

這樣做的目的是為了提高代碼的可重用性，避免重復(fù)造輪子。另外，也有利于代碼之間的解耦。

比如：

- src/
  - data/                    # 常量、靜態(tài)數(shù)據(jù)目錄
    - data1.js          
    - data2.js
    - ...          
  - components/              # 組件目錄
    - componnet1/          
    - componnet2/
    - ...          
  - utils/                   # 工具函數(shù)目錄
    - util1.js          
    - util2.js
    - ...     
  - ...     

可以參考：組件化。

這里的可閱讀性有兩個(gè)方面：目錄文件結(jié)構(gòu)、代碼結(jié)構(gòu)。

目錄文件結(jié)構(gòu)可閱讀性的好與否除了跟開發(fā)者有關(guān)系外，跟項(xiàng)目的搭建者也有很大的關(guān)系，因?yàn)槿绻罱ㄕ咴谧畛蹙投x好整個(gè)項(xiàng)目的目錄結(jié)構(gòu)，對(duì)后期的開發(fā)者是一個(gè)很好的約束。

可閱讀性比較差的目錄文件結(jié)構(gòu)：

- 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 頁面
      - ...

可閱讀性比較好的目錄文件結(jié)構(gòu)：

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

關(guān)于目錄文件結(jié)構(gòu)的高可讀性，可以參考：目錄結(jié)構(gòu)優(yōu)化。

代碼結(jié)構(gòu)的可閱讀性大部分取決于開發(fā)者的水平，但我們可以使用工具幫助開發(fā)者書寫規(guī)范、格式良好的代碼。

主要有下面的工具：

.editorconfig: 統(tǒng)一每個(gè)開發(fā)人員的編輯器配置

eslint: 檢查 js 語法（包括 jsx 語法），然后最大程度的矯正不符合規(guī)范的代碼

stylelint: 檢查 css 語法（包括 less, scss 語法），然后最大程度的矯正不符合規(guī)范的代碼

prettier: 代碼格式優(yōu)化

husky + lint-staged: 強(qiáng)制開發(fā)人員對(duì)代碼進(jìn)行檢查、自動(dòng)矯正與優(yōu)化

上面的具體用法可以參考：

怎樣提升代碼質(zhì)量

搭建自己的前端腳手架

可能的情況下，讓項(xiàng)目具有一定的伸縮性，可以在未來輕松的對(duì)項(xiàng)目進(jìn)行架構(gòu)升級(jí)。

讓項(xiàng)目能夠輕松的移植某些頁面、組件、模塊到其他項(xiàng)目，需要對(duì)整個(gè)項(xiàng)目代碼盡量的解耦與模塊化。另外，也與后面會(huì)講到的“項(xiàng)目之間的統(tǒng)一性”有關(guān)。

對(duì)頁面、組件的重構(gòu)是常有的事，但怎樣保證在重構(gòu)之后功能不會(huì)改變、不會(huì)產(chǎn)生新 bug，這就得靠測(cè)試用例了。

js 模塊：jest / mocha / tape / ava

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

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

可以參考：

react 前端項(xiàng)目技術(shù)選型、開發(fā)工具、周邊生態(tài)

vue 前端項(xiàng)目技術(shù)選型、開發(fā)工具、周邊生態(tài)

這主要是從目錄結(jié)構(gòu)優(yōu)化著手，比如：

像下面這種目錄結(jié)構(gòu)，如果要編輯一個(gè)頁面，需要到處找頁面相關(guān)的文件，編輯器上就會(huì)形成一個(gè)很長(zhǎng)的目錄樹，一點(diǎn)不友好：

- src/
  - css/                     # css 集合
    - main/                  # main 目錄
      - alpha.css
      - beta.css
      - ...        # 中間有 30 個(gè)頁面
  - js/                      # js 集合
    - main/                  # main 目錄
      - alpha.js
      - beta.js
      - ...        # 中間有 30 個(gè)頁面
  - html/                    # html 集合
    - main/                  # main 目錄        
      - alpha.html           # alpha 頁面
      - beta.html            # beta 頁面
      - ...        # 中間有 30 個(gè)頁面

而像下面這種目錄結(jié)構(gòu)，所有的文件都在一個(gè)目錄下，找文件就很方便，而且很清晰：

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

當(dāng)項(xiàng)目變大、多人協(xié)作時(shí)，我們就需要管理好哪些是正在開發(fā)的代碼、哪些是提交測(cè)試的代碼、哪些是已經(jīng)上線的代碼、如何避免代碼沖突與線上新代碼被舊代碼覆蓋等等。

具體可以參考：web 項(xiàng)目如何進(jìn)行 git 多人協(xié)作開發(fā)。

當(dāng)有人要離開項(xiàng)目時(shí)，就需要把他負(fù)責(zé)的代碼交接給別人，但怎么樣才能使交接是輕松愉快的？

那就是文檔，包括注釋文檔、接口文檔等。想想，如果沒有文檔，該怎樣交接呢？

可以參考：api 接口管理工具。

多個(gè)項(xiàng)目之間，如何管理好項(xiàng)目之間聯(lián)系，比如共用組件、公共模塊等，保證快捷高效開發(fā)、不重復(fù)造輪子，也是很重要的。

一般會(huì)從下面幾點(diǎn)來考證多個(gè)項(xiàng)目之間是否管理得很好：

組件化：多個(gè)項(xiàng)目共用的代碼應(yīng)當(dāng)獨(dú)立出來，成為一個(gè)多帶帶的組件項(xiàng)目

版本化：組件項(xiàng)目與應(yīng)用項(xiàng)目都應(yīng)當(dāng)版本化管理，特別是組件項(xiàng)目的版本應(yīng)當(dāng)符合 semver 語義化版本規(guī)范

統(tǒng)一性：多個(gè)項(xiàng)目之間應(yīng)當(dāng)使用相同的技術(shù)選型、UI 框架、腳手架、開發(fā)工具、構(gòu)建工具、測(cè)試庫、目錄規(guī)范、代碼規(guī)范等，相同功能應(yīng)指定使用固定某一個(gè)庫

文檔化：組件項(xiàng)目一定需要相關(guān)的文檔，應(yīng)用項(xiàng)目在必要的時(shí)候也要形成相應(yīng)的文檔

這里的組件化是項(xiàng)目之間的組件化，我們可以把多個(gè)項(xiàng)目共用的代碼獨(dú)立出來，成為一個(gè)多帶帶的組件項(xiàng)目。

這樣做的目的也是為了提高代碼的可重用性，避免重復(fù)造輪子。另外，也便于版本化管理組件。

- project1/                  # 項(xiàng)目一
  - package.json
  - src/ 
  - ...
  
- project2/                  # 項(xiàng)目二
  - package.json
  - src/ 
  - ...  
  
- component1/                # 組件一
  - package.json
  - src/ 
  - dist/ 
  - ...
  
- component2/                # 組件二
  - package.json
  - src/ 
  - dist/ 
  - ...    

在 project1 中使用 component1、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: 常用靜態(tài)數(shù)據(jù)

...

組件化一般會(huì)與私有 npm 倉庫一起使用。

可以參考：

組件化

私有 npm 倉庫

如果應(yīng)用項(xiàng)目使用 npm 來管理依賴，就是版本化管理了。

組件項(xiàng)目更不用說了，值得提一下的是組件項(xiàng)目的版本號(hào)應(yīng)當(dāng)符合 semver 語義化版本規(guī)范。

版本格式：主版本號(hào).次版本號(hào).修訂號(hào)，版本號(hào)遞增規(guī)則如下：

主版本號(hào)：當(dāng)你做了不兼容的 API 修改，
次版本號(hào)：當(dāng)你做了向下兼容的功能性新增，
修訂號(hào)：當(dāng)你做了向下兼容的問題修正。

先行版本號(hào)及版本編譯元數(shù)據(jù)可以加到“主版本號(hào).次版本號(hào).修訂號(hào)”的后面，作為延伸。

可以參考：

從 1 到完美，寫一個(gè) js 庫、node 庫、前端組件庫

從 0 到 1 再到 100, 搭建、編寫、構(gòu)建一個(gè)前端項(xiàng)目

多個(gè)項(xiàng)目之間應(yīng)當(dāng)使用相同的技術(shù)選型、UI 框架、腳手架、開發(fā)工具、構(gòu)建工具、測(cè)試庫、目錄規(guī)范、代碼規(guī)范等，相同功能應(yīng)指定使用固定某一個(gè)庫。

這樣做的目的是減少項(xiàng)目之間的環(huán)境差異，有利于項(xiàng)目之間的代碼移植，也更有利于組件化、代碼重用。

可以參考：

react 前端項(xiàng)目技術(shù)選型、開發(fā)工具、周邊生態(tài)

vue 前端項(xiàng)目技術(shù)選型、開發(fā)工具、周邊生態(tài)

搭建自己的前端腳手架

通用、封裝、簡(jiǎn)化 webpack 配置

完善的文檔，不管是對(duì)組件項(xiàng)目還是應(yīng)用項(xiàng)目，都是很重要的。

組件項(xiàng)目需要用文檔告訴開發(fā)者組件怎么用、有哪些接口；應(yīng)用項(xiàng)目需要用文檔來做小組交流、項(xiàng)目交接等。

更多博客，查看 https://github.com/senntyou/blogs

作者：深予之 (@senntyou)

版權(quán)聲明：自由轉(zhuǎn)載-非商用-非衍生-保持署名（創(chuàng)意共享3.0許可證）