App元件化與業務拆分那些事
鍵盤男的部落格地址:
http://www.jianshu.com/users/0ef3dc77079c
2
為什麼要元件化、模組化
專案存在問題
-
程式碼量大,耦合嚴重
-
編譯慢,效率低
-
業務開發分工不明確,開發人員要關心非業務的程式碼
-
改程式碼時,可能會影響其他業務,牽一髮動全身
優點
-
架構更清晰,解耦
-
加快編譯速度
-
業務分工明確,開發人員僅專注與自己的業務
-
提高開發效率
-
元件、業務獨立更新版本,可回滾,持續整合
元件化與模組化
元件、模組,中文字面意思相近,在英文上都可以翻譯為"Module",加上Android Studio上,library被稱為"Module",這就不難解釋為什麼我們談到“元件化”、“模組化”,兩者之間的區別相當的模糊。
元件
App工程上所說的 元件,應該翻譯為“Component”,意思是元件、部件、元件。在電子電路中,電子元件是電子電路中的基本元素。在App工程上,元件是構成業務或者功能模組的基本單位。原則上,元件與元件之間互不依賴。
例如,圖片上傳功能,應該叫“圖片上傳元件”,而不是“圖片上傳模組”。因為圖片上傳從功能、業務上,已經不能往下拆了。
圖片上傳可能使用七牛sdk,或者又拍雲sdk。無論圖片上傳元件用七牛sdk,還是又拍雲sdk,都不會影響這個元件的功能,因此元件具有可替換性;同時,圖片上傳元件可以被多個業務使用,因此元件具有可複用性。由於sdk只是技術細節,它跟業務並沒有關係。在業務架構圖上,也不會出現“xx sdk”,因此我們說圖片上傳元件不能拆分了。
同理,日誌功能,叫“日誌元件”,不叫“日誌模組”。
模組
模組翻譯為“Module”,字面意思。模組由多個元件構成,它可以實現一個獨立的功能,甚至業務。
例如,大眾點評的美食功能,是一個業務,可以叫“美食模組”,習慣上叫“美食業務”。它可以拆分更小的模組:搜尋、簽到、評論等。
兩者關係
從上面的闡述可以得出,一個工程,由多個模組組成,每個模組由多個元件構成。但很多時候,兩者界限還是相當模糊。例如“日誌元件”稱為“日誌模組”,也沒有違和感。
-
元件從業務角度上不能繼續拆分,可替換,可複用;
-
模組的定義比較籠統,可以是一個Business業務,可以是技術架構中一個業務,也可以是幾個元件構成的小功能。
無論是元件化還是模組化,目標都是把臃腫的工程,拆分為更小的部分,解耦各種複雜的邏輯,便於程式碼管理。
4業務劃分
一個產品的業務,其實是在規劃產品功能,或者做產品原型時,已經定好了(如果連產品或者老闆都沒這概念的話,我們還是算了);如果後端牛逼的話,他們也會做業務劃分,每個業務部署到獨立的容器、虛擬機器、伺服器。所以,我們做業務劃分時,可以諮詢後端,也可以諮詢產品經理。
例如,大眾點評,首頁已經展示了好多個業務:美食、電影、酒店、休閒娛樂、外賣、機票/火車票..... 這種多業務APP,通常會把業務儘量展示在首頁,這種APP大的業務很好劃分。美食、電影這類看起來完全不同的業務,筆者稱為Business業務。
但並不是這樣劃分就OK了,好像大眾點評這種超級APP,每個Business業務都能分成很多基礎業務。例如,美食業務,可以搜尋商鋪、預約、使用優惠券、點評、簽到等;同時,電影業務也有搜尋、優惠券、點評等。所以,搜尋商鋪、優惠券、點評這種基礎業務,可以獨立出來,被多個Business業務使用。
元件與業務
上文提過,多個元件構成一個模組,當模組相當於業務時,就是說該業務由多個元件組合而成。
還是拿大眾點評做例子,點評基礎業務,釋出點評需要上傳圖片、網路提交、記錄本地日誌等,那麼需要呼叫上傳圖片元件、網路元件、日誌元件等。
不僅僅點評業務呼叫,所有業務都會呼叫這些元件。於是,業務架構如下:
Business業務 -> 基礎業務 -> 各種元件
業務與業務
情景1
場景:在大眾點評訂了酒店,入住之後,開啟該酒店詳情頁,大眾在“推薦列表”給你推薦若干大保健......
情況1:
前端H(負責酒店業務H):後端D,麻煩給酒店業務單獨做個推薦大保健的api。
後端D(負責大保健業務D):大保健業務有api D,你呼叫api D吧前端在酒店業務Module,寫了呼叫api D,功能上線。
=============================================================
過了一段時間,大保健業務做了調整,資料變動、改域名等。後端D:前端H,api調整了,麻煩呼叫api D改為呼叫api D1。
前端H:現在好忙,我加班搞吧。於是前端H加班改程式碼,還要做單元測試等一系列工作。
=============================================================
又過了一段時間,大保健業務再次資料變動。後端D:前端H,api D1改成api D2。
前端H:怎麼又改.....
本來前端H是做酒店業務的,為了大保健的推薦列表,不得不因為大保健業務調整,而加班加點。再延伸一下,如果酒店業務H還需要呼叫電影院列表、美食列表.....每個業務的改動,前端H就呵呵了。
情景2:
當然了,要前端不改動,後端保持原來api D也可以的。只不過,會引發下面對話:
前端H:後端D,不過你一直提供api D給其他業務使用,當資料調整時,api D做好相容我們就不用改了。
後端D:你傻逼啊,相容多麻煩,我們很忙的,你們不就改一點程式碼嗎?我們還要#&^@&#$"@*#......
維護相容/對外開放介面確實是一種解決方法,只不過會加重後端開發、運維的工作量,長期來看並不科學。
情景3:
如果在前端業務與業務在獨立的情況下,也可以相互呼叫,那就簡單多了:
前端H:前端D,麻煩寫一個介面,讓其他前端業務可以請求大保健推薦列表。
前端D(負責大保健業務D),沒問題,你呼叫D類getHealthCare(),就會請求大保健推薦列表,並返回你要的資料了。=============================================================
過了段時間,大保健資料變動。前端D在前端大保健業務D做了api D->api D1改動,並對D類getHealthCare()做了資料相容,前端H不需要額外改程式碼。
從上面3個情景看,情景3是最優的做法,前端H並不需要跟後端D對接,大保健業務D改動,後端D不需要通知前端H,只需要跟前端D對接即可。而前端的相容工作,比後端相容工作要簡單得多。
7業務之間跳轉
業務之間跳轉,這個話題老生常談了。無論是Android、iOS,都是URL Schame跳轉這種解決方案。原因是url不需要任何依賴,而且可傳遞引數。
業務資料互動
無論前端、後端,業務之間資料互動,都是很重要的環節,選用何種合適的方案,就體驗架構師的水平了。
未做業務拆分時,直接呼叫其他業務的程式碼即可:
-資料直接互動,強耦合-
但業務拆分後,就不能直接呼叫程式碼了。兩個業務相互獨立,程式碼互不依賴,必須用某種協議(常用json)用資料。
-間接互動,服務中心做資料中轉-
如果其他業務需要獲取大保健資料,首先大保健業務要註冊大保健服務到服務中心,其他業務才可以通過協議呼叫這個服務。
-業務相互呼叫-服務中心-
如何註冊服務,Android和iOS都有不同的做法,而且方法不止一種。本文僅提供思路,技術細節,會在之後的文章闡述。
其實元件與元件之間,也存在相互呼叫的情況,可參考這種做法。
9小結
元件化、拆分業務後:
單一職責:開發人員專注於自己的業務
依賴倒置:上層業務依賴下層業務,業務依賴元件,業務之間、元件之間不相互依賴
介面隔離:業務之間呼叫資料,通過統一的協議與服務中心互動,不呼叫業務實際程式碼
程式碼質量與規範程度明顯提高,高內聚、低耦合。業務職責分明,單元測試也更好寫。如果業務拆分做得好,可以一個業務一個單獨工程編譯,不僅大幅提高編譯速度,而且業務程式碼還可以回滾、版本釋出等。
一切為了更清晰的架構、更乾淨的程式碼^_^