Group 還是Feature
先上下前后兩個項目的結構對比圖：
舊的項目采用Group的方式，MVC結構，問題如下
- 隨着項目的復雜度不斷上升，Controller，View文件夾變得異常龐大，定位某個具體業務對應的頁面往往取決於文件名命名的好壞。
- 具體業務的Controller，View，Model文件過於分散，通常無法在文件目錄里面全部顯示，不利於閱讀，也不便於對應文件之間的跳轉
- 如果多人開發，則代碼在文件夾層次必然相互干擾。
新的項目采用Feature方式，MVVC結構，優點如下：
- 模塊的區分便於理解產品的功能，文件的層次也基本反映了實際頁面上的層次關系，便於快速定位到代碼文件
- 便於協同開發，各人僅需維護自己的Feature文件夾，進行單元測試，減少了合並沖突的問題
- 同一Feature的Controller，View，Model， ViewModel在同一目錄，便於閱讀
具體
- vender：第三方庫，大部分第三方庫均采用cocoapod方式引入，其他要源碼引入的一般放在這里
- Feature：業務具體模塊，可以按功能進行划分，例如Login，More，Game
- Manage：管理類，通常封裝了對應用的某一塊操作，例如網絡請求管理模塊，緩存管理模塊，下載管理模塊。
- Utilite：工具模塊，通常包括自定義的界面控件，對第三方庫的簡單封裝類，通用工具函數類（與Manage主要區別在於Utilite復用性更強，而Manage則與項目耦合更緊密）
- Application:這個group中放的是AppDelegate和一些系統常量及系統配置文件
- Storage：簡單數據存儲，主要是一些鍵值對存儲及系統外部文件的存取，包括對NSUserDefault和plist存取的封裝；
- Database：數據層，封裝基於FMDB的sqlite數據庫存取和管理(RTDatabaseHelper)，對外提供基於Model層對象的調用接口，封裝對數據的存儲過程。
- Resource：資源庫，包括圖片，plist文件等
- General：主要包含Additions，Macros文件夾，其中Macros包含
- NotificationMacro：通知宏定義文件
- AppMacro：應用內外網接口，APP_ClientId等和應用相關的宏
- UtilsMacro: 常用代碼簡寫相關
- UrlMacro: web請求接口路徑對應的宏，將請求地址統一管理，便於查找與更新
- EnumMacro：項目里面枚舉一部分直接定義在所用枚舉的文件頭部，另一部分統一放在該文件，權衡的依據是如果枚舉僅僅只跟界面相關，或者寫了個通用類，反之，這些與業務相關的代碼應該歸到EnumMacro
作者：二木又土
鏈接：https://www.jianshu.com/p/a0b4a894d58a
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。