前端項目管理不得不知的那些技巧

前端項目管理不得不知的那些技巧

前端項目如何管理

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

1. 項目內的管理

在一個項目內,當有多個開發者一起協作開發時,或者功能越來越多、項目越來越龐大時,保證項目井然有序的進行是相當重要的。

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

  • 可擴展性:能夠很方便、清晰的擴展一個頁面、組件、模塊
  • 組件化:多個頁面之間共用的大塊代碼可以獨立成組件,多個頁面、組件之間共用的小塊代碼可以獨立成公共模塊
  • 可閱讀性:閱讀性良好(包括目錄文件結構、代碼結構),能夠很快捷的找到某個頁面、組件的文件,也能快捷的看出項目有哪些頁面、組件
  • 可移植性:能夠輕鬆的對項目架構進行升級,或移植某些頁面、組件、模塊到其他項目
  • 可重構性:對某個頁面、組件、模塊進行重構時,能夠保證在重構之後功能不會改變、不會產生新 bug
  • 開發友好:開發者在開發某一個功能時,能夠有比較好的體驗(不好的體驗比如:多個文件相隔很遠)
  • 協作性:多人協作時,很少產生代碼衝突、文件覆蓋等問題
  • 可交接性:當有人要離開項目時,交接給其他人是很方便的

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 代碼結構

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

主要有下面的工具:

  • .editorconfig: 統一每個開發人員的編輯器配置
  • eslint: 檢查 js 語法(包括 jsx 語法),然後最大程度的矯正不符合規範的代碼
  • stylelint: 檢查 css 語法(包括 less, scss 語法),然後最大程度的矯正不符合規範的代碼
  • prettier: 代碼格式優化
  • 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

可以參考:

  • react 前端項目技術選型、開發工具、周邊生態
  • vue 前端項目技術選型、開發工具、周邊生態

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 協作性

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

具體可以參考:web 項目如何進行 git 多人協作開發。

1.8 可交接性

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

那就是文檔,包括註釋文檔、接口文檔等。想想,如果沒有文檔,該怎樣交接呢?

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

2. 多項目之間的管理

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

一般會從下面幾點來考證多個項目之間是否管理得很好:

  • 組件化:多個項目共用的代碼應當獨立出來,成為一個單獨的組件項目
  • 版本化:組件項目與應用項目都應當版本化管理,特別是組件項目的版本應當符合 semver 語義化版本規範
  • 統一性:多個項目之間應當使用相同的技術選型、UI 框架、腳手架、開發工具、構建工具、測試庫、目錄規範、代碼規範等,相同功能應指定使用固定某一個庫
  • 文檔化:組件項目一定需要相關的文檔,應用項目在必要的時候也要形成相應的文檔

2.1 組件化

這裡的組件化是項目之間的組件化,我們可以把多個項目共用的代碼獨立出來,成為一個單獨的組件項目。

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

- project1/ # 項目一
- package.json
- src/
- ...

- project2/ # 項目二
- 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: 常用靜態數據
  • ...

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

可以參考:

  • 組件化
  • 私有 npm 倉庫

2.2 版本化

如果應用項目使用 npm 來管理依賴,就是版本化管理了。

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

版本格式:主版本號.次版本號.修訂號,版本號遞增規則如下:

  • 主版本號:當你做了不兼容的 API 修改,
  • 次版本號:當你做了向下兼容的功能性新增,
  • 修訂號:當你做了向下兼容的問題修正。

先行版本號及版本編譯元數據可以加到“主版本號.次版本號.修訂號”的後面,作為延伸。

可以參考:

  • 從 1 到完美,寫一個 js 庫、node 庫、前端組件庫
  • 從 0 到 1 再到 100, 搭建、編寫、構建一個前端項目

2.3 統一性

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

這樣做的目的是減少項目之間的環境差異,有利於項目之間的代碼移植,也更有利於組件化、代碼重用。

可以參考:

  • react 前端項目技術選型、開發工具、周邊生態
  • vue 前端項目技術選型、開發工具、周邊生態
  • 搭建自己的前端腳手架
  • 通用、封裝、簡化 webpack 配置

2.4 文檔化

完善的文檔,不管是對組件項目還是應用項目,都是很重要的。

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


分享到:


相關文章: