我們在做元件化之前，必須要弄清楚，我們為什麼要元件化，如果沒有明顯的優點，或者解決我們的所需，我們沒有必要元件化。在app迭代如此快速的情況下，耗費時間精力去做這麼一件事情到底值不值得？

一、元件化所解決的問題

1.程式碼複用

程式設計發展至今，面嚮物件語言的技術點發展，大多解決的是程式碼可複用問題，不管是封裝、繼承、多型，都是解決程式碼重用的不同解決方案，而元件化也是為了這個目的，將一個業務、一個功能、甚至一段程式碼元件化，以達到複用的目的。

2.功能解耦合

功能解耦也可以說是貫穿整個程式設計發展的任務，為了程式碼複用的精準，自然也就要求其元件化出去的程式碼能夠解耦，不依賴其他的程式碼，否則像葡萄似的一串串的，有用的沒用的都需要拿走，那程式碼複用的的初衷就變得很迷了。

3.原始碼管理

伴隨著app的發展，app越來越複雜，開發人員也自然的越來越多，一般的開發人員分為不同等級，水平自然參差不齊，那麼對於原始碼的管理則尤為重要，但是隨著人員的增多，git程式碼上傳、merge將會是一個巨大的工作，就算是經驗豐富的工程師也未免出錯，耗時嚴重、錯誤頻出將會是一個大團隊所經常面對的問題

二、怎麼做元件化

基於上述問題，我們的解決方案自然也是呼之欲出：
1. 將可重用的程式碼提取
2. 將提取的程式碼去耦合
3. 單獨管理提取的程式碼
4. 為提取的程式碼新增接入工程的方法

做完上述工作，我們可以說，這段提取的程式碼已經元件化了。
PS：當然業務元件化的任務不同，更偏向的是業務的解耦而非程式碼重用。

三、工程元件化

根據工程程式碼的不同分工，我們分為幾個級別的程式碼，並根據這幾個級別的程式碼分出輕重緩急，然後去相應的做元件化工作。

1. 基礎功能

這裡的基礎功能對應iOS來說，可以分為幾類：
（1）巨集定義工具
（2）類目功能擴充套件
（3）工具類
（4）UI類
當然類是死的，對於APP來說，其他的認為是基礎的都可以放在這裡，但是建議遵循一個原則，基礎功能不管放到任何一個app裡面都是可以的使用的，而且儘量少的增加該app的負擔，比如不常用的庫或功能等，基礎應為儘量小。

2. 公共業務功能

這裡面的東西主要是自己app的公共業務，比如埋點、分享、通訊錄等可能各個業務線都需要用的功能，且自己的app有些定製化的功能，這部分根據app規模可能會很大，

3. 獨立業務功能

這裡面主要就是各個業務的功能，根據業務數量可能會有多個業務元件，另外像登入、註冊等功能如果自己的app不適合放到公共業務裡面，也可以當做平臺業務由平臺提供功能。

上述三個分類也相互有了彼此的依賴：基礎功能->公共業務->獨立業務

四、元件化準備工作

上述分類也明確的給出了一個元件化的程序方案，也就是先做基礎功能的元件化，再在此基礎上抽離公共業務，最後進行獨立業務的元件化。

但是我們開始這些工作前，我們還需要一些技術準備工作，在（二）中，我將講述準備工作都有什麼，並如何去做。