最近越来越感到进阶之路的困难，和发展之路的不明确，值此之际，特想写一篇文章，来总结下，结束这种混乱状态。
由于目前在团队中角色的转换，管理团队的重任也落在自己身上了，除了技术方面之外，现在任务更重了，不能只关注单点的技术细节了，更多地应该从全局 ，从整体方面去思考,提高团队整体的规范性和开发效率。
有三大主要的任务：
（1）团队管理：任务分配和沟通
（2）技术：指导 规范 工程结构和架构
（3）审核：code review，规范。
在这其中呢，也是困难重重啊，一时还难以适应，经常会因为修改bug，而导致团队管理方面沟通的欠缺，以及没有时间去好好设计工程结构，导致一时间的混乱状态，今天突然想到了也许可以写一篇文章来好好思考一下。
鉴于排版还不是很熟，将就着看吧。
首先呢，就是iOS app开发的 工程结构问题。
一般呢，我现在这样划分：
BaseClass： BaseView，BaseModel，BaseController
UIComponent: 基本的UI组件，与项目 业务 和界面无关的 快速开发组件，最常见的就是 TableView CollectionView 高度集成化的组件。
Resources ： 本地一些资源文件，txt plist 音频等等
ThirdLibrary: 三方库
WebService：网络请求以及网络层 ，这一层里面会有涉及一些设计设计模式运用，以及dataModel的引用，交付给 Controller
Utils：里面包括各大组件的 工具方法，常用的小功能的封装方法，三方分享，三方支付，三方地图定位，等等以及一些category 方法，工程配置的Macro，配置文件，这些都是工具
Modules ：模块化。每个大的功能模块，这个一般基于 tabbar+navigation的结构，每个模块中 可能会有定义Mediater，每个模块 ViewModel的交付， 跨模块调用的话，ModuleMediator的使用，统一管理配置。
Hybird：基于WebView 的OC js双向交互，以及html文件及时下载到本地的插件化。先这么交吧。可能需要 调用Util里面的 类来实现操作。 这个里还可能包含 html css js等文件，接口提前定义好。
总原则呢：就是 可维护，可读，然后就是尽量 模块化，组件化，功能性的小模块 高内聚，低耦合。
工程结构讲完了，下面说说我所认为的对开发项目有所帮助，也就是对代码可读性，可维护性有帮助的一些共识。
（1）肯定就是命名了， 常量统一 static xx const xx ，变量命名驼峰命名，首字母小写，例如settingBtn，通知 如kNotificationSwitchLogin，
（2）对于我们经常运用的 UIViewController ，代码组织如下：
#pragmamark-Lifecycle
-(instancetype)init{}
-(void)dealloc{}
-(void)viewDidLoad{}
-(void)viewWillAppear:(BOOL)animated{}
-(void)didReceiveMemoryWarning{}
#pragma mark–Create UI
-(void)createUI{
}
#pragmamark–Load Data
-(void)loadData{}
-(void)request{}
#pragmamark-CustomAccessors
-(void)setCustomProperty:(id)value{}
-(id)customProperty{}
#pragmamark–Event Response
#pragmamark-Protocolconformance
#pragmamark-UITextFieldDelegate
#pragmamark-UITableViewDataSource
#pragmamark-UITableViewDelegate
（3）基本的多处用到的 公共view，例如选择，提供统一的接口，和回调接口，给定指定数据格式，选择完即可返回我们所需要的东东，这个问题呢，封装的view 提供对外的接口一定要简单易用，其他显示，收起使用者不需要管理， 这点很关键。就比如
+(void)showWithArr:(NSArray*)arr pickType:(PickType)pickType picked:(AddressPickerControllerBlock)block;
命名不太规范啊,但是大概意思是这样，arr，为结构化的数据，里面可能是 dict，model，写接口的时候，数据格式自定义完，约束相关者给定指定的数据格式。
pickType 为 single和double，
block 回调给我们需要的数据。id and name。
（4）基本的操作硬件类的东东，比如拍照，选图片， 隐藏内部细节，高内聚，外观模式的运用，提供一个高度简化的接口，调用完回调，等等，而不是重复作业哦。 劲酒虽好，可不要贪杯噢。
（5）尽量做到 少if else 的判断逻辑，能细化成可配置，可替换的最好。 小技巧，就是 用字典来配置，其他就是策略模式的运用，替换类了。不同逻辑，不同类了。
（6）针对接口编程，而不是针对实现，这可是很有学问的，多定义接口，这样很灵活，只要做到 替换一个包装一定行为的对象即可。很多时候就可以做到一定的可扩展性，而不用修改逻辑代码，修改细化的类即可。/继承和组合的取舍
说完基本的结构和共识，就轮到下面的 主题了。其实上面说的也已经体现出了一定的架构了，组件化的思想喽。哈哈。
目前市面上的架构通常是这样的，天下架构出自MVC，子MVC基础之上衍生出来一些架构。
例如 MVVM 三层架构 MVP架构 CDD架构，眼花缭乱啊。这就需要我们 自己结合自己公司的业务和项目类型，总结一套属于自己的架构了。
