Lego組件平台開發（一）
- 2019 年 12 月 4 日
- 筆記
本文作者：IMWeb 劉恆兵 原文出處：IMWeb社區 未經同意，禁止轉載
Lego組件平台開發（一）
@(lego平台)
為什麼要做組件平台
為什麼要組件，這個問題在很多場合都被人提起，這裡不做過多贅述，其解決的本質問題：
- 復用：減少產品、設計(UI)、開發、測試、部署(大型應用)的重複工作量，提升開發效率
- 統一：同一個平台統一產品特性保持高度統一和一致，能做到同步修改。
然後，在任何產品的上線過程中，誰都不願意重複早輪子，都希望能通過一些規範和標準統一起來，後續就完全按照這個標準執行，並能否把歷史上實現過的沉澱出來的直接使用，不需要重複勞動。
這裡就提到的重要的點：1、沉澱；2、標準。如何沉澱？沉澱的標準是？在哪裡沉澱？該不該使用？如何使用？新加入的小夥伴如何知道？
同時，我們還需要解決每個組件之間的依賴（即模組依賴），就需要一個平台來幫我們做這樣的事情，維護組件，而且能做到工具化，和構建體系打通，使用者能快速方便地相信和使用組件。這裡就提到一個重要的問題：工具、維護
從組件的維護髮展歷史來看有以下一些方式：
- svn：把一些組件抽離出來，放到程式碼管理系統，使用者通過既定的發現路徑，招到組件，下載使用。這種方式效率相對比較低，團隊內部都不一定能知道對方有什麼組件，外部更不用說了。
- github：相對於svn來講，除了程式碼託管之外，比較優勢的地方是開源化，可以在這個平台找到很多有類似功能的組件。同時，還可以參與貢獻和回饋，提升組件。然後，對於使用者來講，首先要找到自己想要的組件相對麻煩；同時，和自己的構建體系結合，依賴維護等都是比較明顯的問題。
- Npm、Bower，Browserify，Component、Duo、Jamjs等。他們都能解決組件依賴，同時也能和構建體系打通，有很多關於他們對比的文章，這裡不做更多描述。他們在很大程度上解決了我們工作中遇到的問題。但隨著組件的增多，我們逐漸發現，找一個組件（且是自己信任和想要的組件）比較難，只能根據知名度、關注度以及文檔來初步判定，而且沒辦法反哺組件，進一步提升組件
- Spm：這裡之所以單獨列出來，一度我們覺得這個是離我們目標最近的組件管理平台，他包括了組件初始化、編碼、本地化調試、文檔生成、發布、依賴管理、單元測試、構建、源服務等功能。
而我們理想需要的一個組件管理平台應該要滿足以下條件：
更新維護文檔調試依賴管理構建體系單元測試快速發現品質認證使用回饋
那麼，現有的哪個平台離我們最近呢？之前的分析可以看到，離我們最近的是spm，基於spm我們可以打造出我們理想目標的組件管理平台。
如何著手做呢
開始之前我們得明確自己的目標，有了目標之後我們得確定規範，然後才能開始行動。
規範
每一個組件平台應當有自己的規範，至少應該包含以下規範
當然這裡的運營規範是後面補充的，早期我們確定了程式碼採用commonjs規範，後期我們打通了基於fis3的構建體系fis3-hook-lego。其他構建體系下的插件也會逐漸放出來。
全景圖
規範確定之後，應當有一個整個平台全景圖的規劃，應該羅列需要包含的功能。
認證流程
其中我們想要的認證體系如下：
平台開發
組件使用
這裡有詳細的組件使用文檔
大致羅列了一下，Lego的產生的背景、規範、使用的指引，後續章節再逐漸解析Lego體系下各個模組運作機制和Lego的理念
