Group 还是Feature
先上下前后两个项目的结构对比图：
1.png
旧的项目采用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则与项目耦合更紧密）
- General：主要包含Additions，Macros文件夹，其中Macros包含
- NotificationMacro：通知宏定义文件
- AppMacro：应用内外网接口，APP_ClientId等和应用相关的宏
- UtilsMacro: 常用代码简写相关
- UrlMacro: web请求接口路径对应的宏，将请求地址统一管理，便于查找与更新
- EnumMacro：项目里面枚举一部分直接定义在所用枚举的文件头部，另一部分统一放在该文件，权衡的依据是如果枚举仅仅只跟界面相关，或者写了个通用类，反之，这些与业务相关的代码应该归到EnumMacro
