多少年前，我有一個夢想：讓世界充滿漂亮小妹。。不！讓世界充滿便捷！
作爲一個程序猴，我是多麼想 只要在屏幕上滑動手指 拖動控件和功能代碼包 ，就可以組裝出一個NB APP，成爲開發效率極高的竄天猴！
雖然沒有實現，但是代碼編程還是要向這個方向發展，也一定會向這個方向發展，這就是所謂的“開發平民化”、“開發0門檻化“！
（ 題外話： 機器編程在未來一定會成爲主流，而其核心就是 “ 獨立的代碼功能塊” 集羣。往深點開發，配上手腳，這就是一個可以實現主人願望的機器人了，但是區別於 深度學習 型機器人。
什麼，啥是集羣？
舉個栗子?：現在的無人駕駛汽車依賴於高速網，這就是爲啥5G NB。但是一旦斷網，汽車計算機就必須在單機模式下行駛到安全區。NB變草雞。。。
這就有了兩種模式：聯網模式和單機模式
單機模式：依賴於自己存儲區的嵌入式代碼，好比 單機遊戲。
聯網模式：有集羣模式和分佈模式。好比 聯網的遊戲。
參考鏈接：https://www.cnblogs.com/xingxia/articles/distribution_concentration.html
機器編程發展方向： 你只需要輸入需求，計算機會根據需求來搜尋並組裝代碼塊 ，完成你的項目 ）
-------------------------- 回到主題分隔線 ------------------------------
扯遠了，讓我們回到主題！要走這條YY出的康莊大道，方向是什麼呢？呵呵呵，這就到了我們的主題：模塊化開發
1 什麼是模塊化開發？
把單一功能進行封裝，使其成爲易用的可複製型代碼，只要暴露的接口OK，寫好文檔就OK。
其耦合性低，方便解耦處理，如：項目A到項目B有相同的功能區，就可以直接拿過去用，不用重複造輪子。
當然，每個公司都自己的代碼庫，公司前輩們已經做好的 那些帶接口的代碼塊 就可以理解成一個所謂的功能單元模塊了。
再次當然，每個人也都有自己的代碼庫，這個就有個人特色一些了。
大夥在看Java或者其他編程語言源碼的時候，會發現一個封裝好的功能有很多的接口，而且做了很詳細的說明與實例講解。
模塊化開發， 說細了就是要做到如底層代碼一樣，不過形式上更像一些小型的、方便易用的SDK。
2 怎麼實現模塊解耦？
解耦要有自己的指導原則，就像八路軍的指導原則是跟黨走一樣。
*模塊功能單一化
一個模塊實現了多個功能固然好用，但是，一旦出bug，代碼糾錯花費的時間和精力都是驚人的！在下作爲一個搞過軟件測試的人，告誡各位一句：多個功能一時爽，一旦出錯火葬場！
舉例：難用的一批的微信支付和百度地圖，功能倒是多種多樣，但是很不人性。
由於其功能多樣，接口複雜，在程序出錯時，你只能一個個的去排查，但是，排查的很多功能都是你用不到的！
*越底層的模塊，應該越穩定，越抽象(具有普適性)，越具有高複用度。
底層基礎決定上層建築。 越是底層的SDK，就應該越穩定，不要總是改來改去。
什麼是底層模塊？
底層模塊包含了總體功能的具體實現方法，也就是說將總體模塊功能解體，分在各個模塊中實現，上層模塊調用底層模塊。
什麼是抽象？
我理解的是考慮到適配各種機型，各種調用情況，具有廣泛適用性。比如多版本APP，不同種類APP，在不同手機系統上都可以調用它，不存在排異性。俗稱：全民老公！
怎麼算是穩定？
穩定的最直觀表現就是API很久都不用變化，所有的變化因子不要暴露出來，避免傳遞給依賴它的模塊。但是要做到設計一套API且很久都不用改變，那麼就需要設計的時候抽象化, 即需要我們有抽象總結的能力。
穩定性 還有一個特點就是會傳遞，比如 B 模塊依賴了 A 模塊，如果 B 模塊很穩定，但是 A 模塊不穩定，那麼B模塊也會變的不穩定了，因此下一個原則：
*提升模塊的複用度，自完備性有時候要優於代碼複用
什麼是自完備性，就是儘可能的依賴少的模塊來達到代碼可複用。
舉個例子，我有個模塊 Utils 裏面放了大量的category工具方法等，在日常UI產品開發中，依賴這個Utils會很方便，但是我現在要寫一個比較基礎的模塊，應該就要求複用度更高一些，這個時候需要用到Utils裏面的幾個方法，那這個時候還適合直接依賴Utils嗎，當然不合適了，這與我們上面的設計原則相悖了啊，因此我們這時候爲了這個模塊的自完備性，就可以重新實現下這幾個方法，而不是依賴Utils模塊。
(注意:
- 按照你架構的層數從上到下依賴，不要出現下層模塊依賴上層模塊的現象 業務模塊之間也儘量不要耦合；
- 自完備性和功能單一性有時候會相互矛盾，一個模塊功能太多和不完善都不是好事，需要自己掌握一個度）
3 面向接口調用
什麼是接口？
接口的特徵爲：只聲明方法，不實現方法。簡單來說，接口是某些行爲的抽象表達，也是一組協議或約定，我們不關心某個具體類，而只關心這個類是否遵守並實現了這些約定。
就像Java 源碼：我們平時調用的方法其實很多就是調用的功能接口，這些個接口給你註明了各個參數和調用的方法。
開發APP的時候，我們發現無論如何解耦，模塊間總是有一些耦合，比如頁面跳轉啊，數據傳遞啊 ，這就好比你想在街上裸奔，卻總有一撮毛擋住了你的胴體，當然是指你的頭髮。想徹底擺脫這些束縛，你就需要面向接口調用了。
因爲只要直接引用代碼就會有依賴。比如
所以我們可以實現一個 getSomeDataFromB 的接口，讓 A 只依賴這個接口，而 B 來實現這個接口，這樣就實現了 A 與 B 的解耦。
這樣就可以實現了即滿足了模塊之間調用，也實現瞭解耦。
至於其優缺點，引用一位同行的總結：
優點：接口 可以非常靈活的定義函數和回調等
缺點：
*接口文件需要放在一個模塊以供依賴。（這個不明白他說的是啥）
*使用麻煩，每個調用都需要一個service,對一些普適性情況不適用，比如 頁面統一跳轉。
其實我覺得 面向接口調用 並不適合用來快速開發，在編寫代碼的前期這項工作會非常耗費你的時間。但是如果你想擁有個人代碼庫，或者你們公司眼光長遠，知道造工具才能幹更多的活計，那你應該堅持這種編程模式。
4 面向頁面調用:
面向接口調用的缺點導致並不能滿足所有的需求，也解耦的不夠徹底，那麼終極手段就是通過定義一套協議來實現模塊間的通信，協議現成的，那就是 “URL跳轉協議”，基本滿足需要，簡單易上手，基本上現在很多的App架構裏面都會有“統一跳轉” 這一套東西的，這個不光是對模塊解耦有幫助，對於統一化運營都是有極好的幫助的，比如app裏面的任何頁面，或者任何操作都是通過一個URL來喚起的話，這樣是不是就把各個複雜的業務之間解耦了呢，通信都使用URL。
關於 頁面跳轉 可以參考 https://blog.csdn.net/weixin_33832340/article/details/87474026
（這類似於 平常我們用到的 APP之間的跳轉，比如微信，你可以通過它暴露的接口直接跳轉到聊天頁面；你也可以在隊列裏面設置自己APP的屬性來供他人調起只要註冊好就OK。 但是2018年蘋果禁止了很多直接的跳轉頁面：比如藍牙、WiFi。估計是因爲越獄後蘋果手機使用風險加大，所以這些年陸續關閉了很多功能，強行會因風險大被拒。也就是說包含prefs:root以及App-Prefs:root的代碼得全部刪除，在info.plist文件中的prefs和App-Prefs的URLSchemes配置也要刪掉。統一使用UIApplicationOpenSettingURLString，會跳轉到對應app的設置頁。）
異議：（蘑菇街APP在模塊通信和跳轉方案中，使用了URL作爲key，用openURL的形式調用模塊。首先，URL的可讀性很差，而且在OC編程中，openURL常作爲App之間的跨進程調用形式，如果作爲App內部模塊間調用用途，則會讓用戶感覺很奇怪。關於蘑菇街的方案，在其他博客裏面也有很多的異議 ，參考鏈接在底部）
5 封裝SDK
本來想講一講的，後來發現一哥們講的特別細緻特別好，總之就是好！我就把他的帖子奉獻給大夥。絕對不是因爲我寫累了想去撩妹子的原因！！！
參考鏈接：https://www.jianshu.com/p/b91f6d297543
6 模塊化的優缺點：
優點：
1、不只提高了代碼的複用度，還可以實現真正的功能複用，比如同樣的功能模塊如果實現了自完備性，可以在多個app中複用
2、業務隔離，跨團隊開發代碼控制和版本風險控制的實現
3、模塊化對代碼的封裝性、合理性都有一定的要求，提升開發同學的設計能力。
缺點：
1、入門門檻較高，新手入門需要的成本也更高
2、工具的使用成本，團隊間和模塊間的配合成本升高，開發效率短期會降低。
3、大型SDK，多功能模塊的糾錯成本高
（ 模塊化看起來是降低了編程的複雜程度及APP開發的成本和時間，但是，卻在一定程度上提高了代碼的複雜程度。
這就在一定程度上帶來了問題：在APP出現Bug的時候，代碼的糾錯複查範圍會更大，舉例：假如一個封裝好的SDK有A、B、C三個功能，你只用到了其中的A、B兩個，那麼當該處代碼出現問題的時候，你需要複查所有的相關代碼區，C功能的代碼區由於和AB區有關聯，你也需要複查。但是，我們用的時候往往只會 重點看 實際應用到的功能的代碼部分，這就會忽略隱藏的風險。）
不過 ，從長期的影響來說，模塊化帶來的好處遠大於壞處，因此其仍然是最佳的架構選擇。
參考鏈接：https://blog.cnbluebox.com/blog/2015/11/28/module-and-decoupling/
---------------------------被識破後的補償-------------------------
7 練習與乾貨：
好吧第5步我確實偷懶了，沒有寫出個人觀點，當然是因爲肚子痛沒寫啦，絕對不是： 因懶生累想撩妹，被人發現急補位。。。爲了補償大家，我決定把我想要收費的項目 公開給大家，聊表心意。。。
鏈接：
---------------------最新： 8 關於組件化和模塊化的探究------------------
最近瀏覽到一位騷年的帖子，有些感悟，特來更貼。
該貼中探究了啥是組件化，什麼是模塊化。個人認爲頗有道理，but,我們如果糾結於一個功能區到底是叫組件還是叫模塊就有些玩文字遊戲，鑽牛角尖了，畢竟我天朝文化博大精深，一個詞可能代表不同的意思。
如果非要規定叫什麼，我們可以按照功能應用範圍來劃分，統一把這些叫做四種模塊。
小模塊:單個功能模塊，所謂的組件等都可以歸爲這一類
特點：解決某個問題-----功能單一，體量小，接口簡單
中模塊：如 百度地圖、支付寶微信支付等SDK，或者你們做的單個業務的功能模塊。
特點：解決某塊的問題------功能全面，裏面可能集成了很多的小模塊
大模塊：集成了其他的APP，可直接叫做“XXAPP模塊”。比如：淘寶集成了其他的APP（天貓、飛豬旅行等），那麼該模塊就可以直接叫做 天貓模塊、飛豬旅行模塊。
特點：解決某方面問題-----這些模塊中可能又有很多的中型模塊，或者其他小模塊。
超大模塊：APP類移動端模塊 、PC類電腦端模塊、服務器類模塊
特點：解決某類問題----一個公司就可以由這些模塊的開發人員組成，這已經跳出了技術範疇，直接指向一個行業了。
參考鏈接：https://blog.csdn.net/u013378438/article/details/85702346