前端陪玩平臺原始碼如何管理

前端陪玩平臺原始碼的管理分為兩個維度：陪玩平臺原始碼內的管理與多個陪玩平臺原始碼之間的管理。

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

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. 多專案之間的管理

多個陪玩平臺原始碼之間，如何管理好專案之間聯絡，比如共用元件、公共模組等，保證快捷高效開發、不重複造輪子，也是很重要的。

一般會從下面幾點來考證多個陪玩平臺原始碼之間是否管理得很好：

元件化：多個專案共用的程式碼應當獨立出來，成為一個單獨的元件專案
版本化：元件專案與應用專案都應當版本化管理，特別是元件專案的版本應當符合 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 倉庫一起使用。

2.2 版本化

如果陪玩平臺原始碼使用 npm 來管理依賴，就是版本化管理了。

元件陪玩平臺原始碼更不用說了，值得提一下的是元件專案的版本號應當符合 semver 語義化版本規範。

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

主版本號：當你做了不相容的 API 修改，
次版本號：當你做了向下相容的功能性新增，
修訂號：當你做了向下相容的問題修正。

先行版本號及版本編譯後設資料可以加到“主版本號.次版本號.修訂號”的後面，作為延伸。

2.3 統一性

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

這樣做的目的是減少陪玩平臺原始碼之間的環境差異，有利於專案之間的程式碼移植，也更有利於元件化、程式碼重用。

2.4 文件化

完善的文件很重要的。
元件專案需要用文件告訴開發者元件怎麼用、有哪些介面；應用專案需要用文件來做小組交流、專案交接等。

本文轉載自網路，轉載僅為分享乾貨知識，如有侵權歡迎聯絡雲豹科技進行刪除處理
原文連結：

前端陪玩平臺原始碼管理是否得當，可以從哪些方面考證？