寫在最前
從開始學寫代碼，胡亂的看書，不懂如何寫第一個程序，到開始寫出第一個程序，這段道路有些漫長。慢慢開始自己獨立的去分析給出的需求，到如何實現，最初的想法只是僅僅實現，到后來懂得如何利用自己技術和經驗去解耦合。自從踏上移動端iOS開發的道路，就開始用過往的技術和經驗去解耦合的道路，也看過各個論壇大牛的各種得意之作。總想着自己造個輪子，雖然不及前人優秀，總會從實踐中提升自身的技術素養，也算是提高自身水平的一次次嘗試吧。
初嘗試
任何軟件開發都需要一系列的入口(通常應該是main函數吧)，而以往開發，會隨着業務需求的增加使入口不斷的膨脹，而且各個業務之間耦合的極其嚴重，到最后不得不去重構甚至重寫代碼。
iOS App經過系統創建進程以及一些列動作后，會交給UIApplicatonDelegate代理，而很多情況下，在代理中大量的冗余臃腫的代碼使維護用來越難以梳理。我要解決的痛點是避免UIApplicatioinDelegate實現類的臃腫與冗余，各個模塊視圖之間實現松散的耦合，內部可以實現強聚合。
我的想法使構建一個封閉的UIApplicationDelegate代理對象(私有實現)，通過兩個配置文件和一個中心對象(EZAppEngine)來接管App控制權，在一個配置文件中基於JSON格式來生產根控制器以及根UIWindow對象，另一個配置文件(plist,以后的打算自己生產一個格式)來配置實現了給定接口(這里使OC的協議)的類。然后將UIApplicationDelegate得不同方法拆分成不同協議，這樣子解決了UIApplicationDelegate本身的臃腫和冗余問題。接下來還有一個問題，就是各個頁面(視圖控制器和模態視圖)之間解耦合，最初我使用一個封裝的對象，通過傳入類名和初始化方法以及參數，來創建頁面，最終使用視圖控制器來確定如何顯示，這個方法雖然減少依賴，但是還是不夠完善。路由思想本身來自Web端的工程，不同的路徑請求被Web服務器分發到各個執行的類中，iOS也可以利用這種思想實現解耦合，並可以跟好解決了WebView和Navtive交互的問題。CocoaPods的出現通過依賴管理以及模塊的路由機制，很好的解決解耦合、模塊復用的問題，通過自動化CI，可以很容易的將各個不同的模塊構建一個新的App.
模塊化+POD私有庫/公有庫+CI總體結構
模塊化結構
我定義了抽象的工具(EZToolUtilites), 網絡封裝(EZServiceUtilites), 核心(EZAppUtitlies)私有庫，EZAppEngine中包含了接口協議定義以及對配置文件的解析，默認會使用當前{Target}.json和{Target}.plist，來完成啟動工作，另外還定義了項目中經常使用的視圖、視圖控制器的類庫。
接下來會通過合適的粒度對業務模塊進行模塊拆分，這個需要一定經驗，對於產品可能不停的迭代和完善的過程。
胡亂寫這么多，接下來繼續完善自己的思路。:P
--
學無止境，逆水行舟不進則退，給自己加油！！！！！