模塊化、組件化與插件化
組件化 modularization、component
模塊化 modularization
插件 plug-in;plug-in component;plug-in module
什么是組件化modularization? 將一部分業務代碼從主工程獨立出去,單獨編譯運行,最后再合并測試并發布的方案得到廣泛運用。這就是組件化
1.實際項目中的組件化問題
- 解決人多(更好的協作)、需求多(更好的功能模塊劃分)的問題;
- 解決項目模塊間的代碼耦合問題;(堅決抵制業務組件間代碼直接引用)
產品業務組件:(例如圈子、1元購、登錄、客服MM等)
- 業務功能間相對獨立,相互間沒有Model共享的依賴;
- 業務之間的頁面調用只能通過UIBus進行跳轉;
- 業務之間的邏輯Action調用只能通過服務提供;
在組件化 / 模塊化之前,蜂鳥商家版 App 的所有代碼 / 資源文件等都是在同一個主工程里的,只有 RN 倉庫或組內公用私有庫等極少部分代碼游離于主工程之外,所以在開發時,每一次都要編譯整個項目的所有代碼,十分低效。這個問題在獨立開發時還不是十分明顯,畢竟雖然項目大但是代碼只有一個人在提交,所以項目代碼量增加也不是那么夸張而且對項目發生的變化比較熟悉。但是當多人協作開發時,這個缺陷就暴露了出來,大家在各自開發不同的業務時,不僅要時刻和他人同步項目變化、讀懂他人代碼,還要每次編譯完整個項目才能對自己所做的一點修改進行調試,效率低下。
- 項目臃腫不堪
- 團隊規模變化
- 業務發展壓力
- 代碼管理混亂
目標
- 加快編譯速度,不用再編譯組件 / 模塊外沒有被依賴到的代碼;
- 便于將每個模塊指定給不同負責人進行管理;
- 降低合并難度,減小沖突和出錯概率,提高業務開發效率;
- 將 Swift 和 OC 代碼進行分離,便于進一步 Swift 化工作的推進;
- 可為模塊編寫單元測試,提高工作效率,同時方便測試人員進行有針對性的測試。
目標設定
- 功能組件獨立:保證所有的底層功能組件從主工程抽出,獨立與主工程之外,便于復用、業務模塊的調用;
- 業務模塊劃分與拆解:將業務按對應用途進行劃分和拆解,想辦法切斷各業務之間的強依賴;
- 所有組件 / 模塊獨立編譯:所有功能組件和業務模塊能夠獨立于主工程進行編譯,有各自的 Demo 工程;
- CocoaPods 發布:在內網 GitLab 進行發布,并且之后對每個模塊用 GitFlow 工作流進行管理和后續發布工作。
三. 計劃制定
組件,就是我們對功能的封裝,一個功能就是一個組件,數據庫、網絡、文件操作、社會化分享等等這些功能都是組件。我們之所以要搞出組件的概念,是為了能夠讓我們的上層業務模塊能夠隨時依賴和調用這些基礎功能。組件基本上可以分為基礎功能組件、通用 UI 組件、基礎業務組件等這幾類。所以為了滿足上述要求,組件必須具有較高的獨立性、擴展性以及復用性。
模塊,就是對一系列有內聚性的業務進行整理,將其與其它業務進行切割、拆分,從主工程或原所在位置抽離為一個相對獨立的部分。僅僅針對業務而言,比如說我們可以把訂單業務獨立為為一個模塊,可以把個人中心獨立為一個模塊,把用戶登錄獨立為一個模塊等,在 App 中的體現就是一個個獨立的 Git 倉庫。模塊化的一個好處是用到時可以搭積木,比如可以多個工程間復用同一個或幾個業務模塊,比如騰訊的 QQ 和 TIM,除了 UI 界面外 TIM 顯然復用了大量現有的原 QQ 工程的業務模塊代碼,當然,我們這里暫時并沒有這個需求。
看了這篇文章會給很多啟發,明白了很多東西
http://www.cocoachina.com/articles/21967
模塊與組件
在一個項目中
個人理解
組件可以組成一個模塊
模塊之間進行相互跳轉
模塊化開發:按照項目業務模塊來劃分,將一個app按業務拆分為登
錄模塊、聊天模塊等等,模塊化其中一個核心的目的就是代碼的高可
復用、高可維護和高可擴展性能。
組件化開發:對應用功能的封裝,一個功能一個組件。比如網絡連接
交互組件、即時通訊IM組件、數據庫組件等。是對模塊化更小的細
分。
最后總結一下
我認為 組件化 還是模塊化
因為項目開發的人數比較多,功能大多比較雜
因此基礎的東西 或者 模塊做成pod當時引入 最為簡單
但是要做成什么樣的 幾個模塊如何互調?是做成pod引入么? 下次再看看