組件化開發之-咱們有什麼必要使用組件化開發？

原創 2016-05-19

背景介紹：
首先簡單說一下爲什我會寫這篇文章呢？ 源於今天討論，提到這個組件化開發和之前沒有多大區別，都須要合做編碼，共同開發某些相同模塊，原本以前都是按照模塊劃分來開發的，既然組件化開發仍是這樣，無非就是將代碼分開編寫而後再相互調用，咱們還須要去搞什麼自動化打包編譯，分包等事情，那麼咱們有什麼必要來組件化開發呢？

   每一個人有不一樣的觀點和體會，這個是很日常的，寫這篇文章不在於想改變誰的想法，也不在於斷定誰的對錯，只是但願可以經過寫出這篇文章來加深一下本身對於組件化開發的理解，同時也但願可以讓別人看到並發現本身在這方面的理解不足之處。但願看到這篇文章的朋友可以回覆更多本身的體會理解。下面就來講一說我在驗證了一段時間的組件化開發的一些小體會：

   先上一張咱們iOS組件化開發架構圖：

組件化開發之於開發測試

• 更加利於開發出MVP（最小可運行版本）
• 項目或者業務愈來愈複雜的狀況下，組件化開發更適合快速迭代，在添加修改組件時候不需擔憂影響其餘組件
• 解決業務模塊劃分不清晰，耦合度大，較難維護
• 可單獨開發，測試，發佈一個組件，不須要像之前同樣開發完某個功能，就須要編譯、運行、打包整個項目
• 某個組件出現問題，可直接對組件進行處理，沒必要擔憂會由於修改而影響到整個工程
• 業務組件之間調用標準化（經過統一的Mediator進行通訊，而非直接引用，下降代碼耦合度）
• 組件只須要提供一種服務能力或者接口，由中間件調用或發現服務，服務對組件間無侵入性
• 組件劃分後，組件的開發不受其餘業務影響，能夠多個組件並行開發，加快開發進度
• 組件能夠提供很好的提高代碼的可重用性（而非可複製性），若是有其餘項目須要該組件能夠直接引入使用，而不是拷貝代碼，拷貝資源等
• 組件單獨測試方便，測試完成後進行集中測試，若是後期有修改組件，只要組件提供的能力或者接口不發生改變，就不須要再次進行集中測試，減小測試工做量
• 若是有新人的加入，能夠直接分配組件進行開發，而非須要熟悉整個項目，能夠從一個組件的開發使新進人員比較快速熟悉項目、瞭解到開發規範

組件化開發之於產品

   長期以來都是產品指導咱們開發工做的進行，若是咱們推行實現了組件化開發，這個能不能在給產品思考的時候帶來點什麼呢（如下只是我的臆測）？

• 是否能夠指導產品需求分析，產品設計也可以融入到組件化開發中來，從產品最初思考角度實現組件化？
• 咱們實現了組件化開發，每個組件的功能描述清晰，是否可以爲產品在與客戶講解或者在客戶有新的需求（注意是需求而非須要）提供參考
• 每每產品須要比開發提早一個或者多個Sprint，能夠從各個組件的實現狀況瞭解到咱們應該須要提早多久
• 組件是否可以更加的體現Agile的MVP（最小可運行版本）
• 經過組件開發完成的結構圖，給運營、銷售講解更加方便簡化，唔須要提供一個比較具體的PRD
• 有時候咱們須要斷定一個需求是否爲真實需求，每每要經過數據反饋來體現，若是經過組件開發快速上線（開放組件內測版本），試錯，是否可以更好更快的定量分析

組件化開發之於銷售、技術支持

• 經過各個業務組件更加精細化的瞭解產品的功能，而非系統瞭解
• 在與客戶溝通時能夠更加專業的告知客戶咱們提供了哪些能力（咱們沒有的能力，特殊需求的客戶能夠自行開發接入）
• 在與客戶溝通後，能夠參與到每一個組件的開發中來，提供建議，而非是對於整個項目提供建議 （這樣每每是沒有記錄下來），對於一個組件提供建議能夠比較快速的作出響應

組件化開發之於UI/UE設計

• 組件分離開來，對於指導UI設計、UE體驗提供約束力，畢竟產品還須要有個開發的規範提供給第三方開發

組件化開發之於Future

• 組件中包含有基礎組件，這些組件也算是技術的一種積累
• 爲將來開發新項目提供更快速的響應

下面是我在組件開發中提供的其餘技術文檔，歡迎查閱：

組件化開發之-Cocoapods使用及建立發佈本身的Pod
組件化開發之-pod建立規範
基於Jenkins搭建iOS持續集成開發環境
基於Jenkins使用Calabash配置iOS功能測試

因爲剛剛開始組件化開發不久，不少好處和不太好的地方還未體會到，此篇文章會在後續持續更新。同時 ** 組件化開發** 系列文章我也會在後面持續輸出。