iOS填坑之1 - 项目越做越大，如何更加规范化管理

人和动物的区别在于人会制造和使用工具

工业革命促使人类解放自己的双手，使的人可以去思考

==============================================
做技术这是第四年了，马上进入第五个年头，越来越熟练的敲代码 ，越来越多的依靠经验来解决问题，但是忙忙碌碌的一年一年，却没有把自己遇到的事儿总结出来，然后给予大家引以为戒是自己的失误。有时候会自恋的思考，哎呀，这算不算是人类的一种损失呢。。。哈哈呵呵嘿嘿恍恍惚惚....

==============================================

小小的说一下在项目中我们用到的一个问题

项目开始的时候，我们对接网络接口使用AFN的POST和GET请求，很好用，也很开心。然后差不多有30个左右的接口，也很容易的就完成~~~撒花。

然后，开始进行二期开发，差不多接口的数目要达到100个的样子，也好呀，也是可以忍受的。

再后来，某天需求出了个小需求，然后跟后台大哥讨论的结果就是：对某些接口新增一个userid的参数，为了保证app的安全，要增加Token验证。

在后来，接口数据依然增加，一直增加一直增加增加，然后需要新增的功能也越来越多

那么问题来了~~怎么才能解决这一系列的问题呢？

1 - 项目技术模板化
2 - 模型数据对接自动化
3 - UI复用界面拆分化
4 - 共用功能集中化（制作Pod库）
5 - 网络请求深入模板化
关于控制团队里面人员代码书写规范的情况，这里不做表述。
iOS项目里面能使用的技术页面/功能模板很多下面介绍我常用的几种

1 - 项目技术模板化 - Xcode 生成基础模板

你安装Xcode之后，~/Library/Developer/Xcode/Templates/ 就是你项目的模板路径，一般常用的ViewController/ TableViewController / View/ TableView /TableViewCell 等等，我们可以创建统一的模板代码，然后在相对应的模块添加相对应的代码就可以了。
我在项目中常用的模板

2 - 模型数据对接自动化 -对接服务器返回数据，直接生成的模型模板

这类模板在此不做直接引用，我也是直接使用的别人的，通过后台返回的JSON数据，直接生成相对应的数据模型，这里再次引用一下就是借助MJEX给予模型赋值，可以不用自己做判空处理，然后使用NSNumber接收int Bool等类型，减少数据的转换。（仅仅是我自己的项目这么用，经过一年多时间的检验，可用）
这类工具使用的方式也多种多样，我们是使用macOS开发，制作了一款基于macOS解析JSON数据的程序，然后直接写文件生成.h和.m（关于这一块内容，会在其他文章中详细解释），拖入项目即可，之前也有使用的插件的方式，但是在XCODE8之后没法使用了，遗憾。

---

3 - UI复用界面拆分化 + 4 - 共用功能集中化（制作Pod库）

公司最多的时候有10个iOS开发人员，开展的项目有7个之多。每个项目的需求和UI搭建都不一样，但是有一些功能是具有共用性质的。例如：TextField 的 是否接受拷贝的功能，TEXTView添加默认的站位文字，+号按钮新增图片，图片轮播与图片浏览等等等...
添加这些UI封装，然后对于每一个UI页面制作相应的config文件，通过文件配置UI的颜色和样式，从而在调用页面只使用一行代码 initWithConfig:(SHConfig *)config andSource:(SHSource *)source就可以实现调用。

基于上面的UI封装，我们将写好的封装内容上传到公司私有控件，通过Pod制作一个简单的XXKIT ，配置和定制config，依托pod制作只的私有控件库。

5 - 网络请求深入模板化

这里只做简单的介绍，我会专门一篇文章介绍和这个模块。
原因比较简单，项目中大约有600个网络请求接口，在每一个控制器中 其实只要 我成功请求或者失败请求的数据模型就可以了。基于这个思想，在AFN基础上封装了XXRquestHelp 来对接POST和GET请求，然后对应每一个功能模块制作相对应的网络请求模块，

/**
*  GET请求
*
*  @param url          请求地址
*  @param parameters   请求拼接所需参数
*  @param successBlock 请求 成功后回调操作
*  @param failureBlock 请求失败后回调操作
*/
+ (void)GETRequestWithURL:(NSString *)url parameters:(id)parameters success:(XXHttpRequestSuccess)successBlock failure:(XXHttpRequestError)failureBlock;

基于AFN封装的POST和GET请求

/**
 *  POST请求
 *
 *  @param url          请求地址
 *  @param parameters   请求拼接所需参数
 *  @param successBlock 请求成功后回调操作
 *  @param failureBlock 请求失败后回调操作
 */
+ (void)POSTRequestWithURL:(NSString *)url parameters:(id)parameters success:(xxHttpRequestSuccess)successBlock failure:(XXHttpRequestError)failureBlock;

基于POST和GET请求，我们要封装关于业务的请求

请求信息@2x.png

建议Header文件使用这个方式书写，便于与某一个服务端联调

建议使用这种样式书写Header文件.png

接口样式

/**
Sale7.x'x'x'x'x搜索列表
@param  userOldId 操作人ID
@param  houPropertyName 物业分期名称
@param  buildingName 楼栋
@param  unitName 单元
@param  roomName 房间号
@param  pageNo 当前页数
@param  pageSize 页大小

*/
+ (void)requestCRsearchSaleCustomerHouseListuserOldId:(NSString *)userOldId houPropertyName:(NSString *)houPropertyName buildingName:(NSString *)buildingName unitName:(NSString *)unitName roomName:(NSString *)roomName pageNo:(NSInteger)pageNo pageSize:(NSInteger)pageSize Success:(SuccessBlock)successBlock failure:(FailureBlock)failure netError:(ErrorBlock)errorBlock;
/**
Sale8.xxx初始化数据
@param  houseIds 房源Id集
@param  userId 操作用户

*/
+ (void)requestCRgetSaleCustomerEvaluateInitDatahouseMsgParamVos:(NSArray *)houseMsgParamVos userId:(NSString *)userId Success:(SuccessBlock)successBlock failure:(FailureBlock)failure netError:(ErrorBlock)errorBlock;

当然，对于对接的后台接口样式，因为老项目繁多，移动端要调用JAVA 、.NET 、PHP等多样的接口，并且接口信息给予的也不一样，所以在请求回调的部分，请对每一个RequestList类单独处理。（谨以此对多后台对接的哥们，表示最崇高的怀念~都是坑，说多了都是泪水）

这样制作网络类的好处很明显，处理数据简单，封装数据安全性有了保证，统一增加参数或者修改参数可以一键修改，多团队模块化开发也互不影响，简直是哈哈哈哈恍恍惚惚.....但是随之而来的只有一个问题：我做了一个比较大的模块，要对接4个部门的后台：部门1 使用JAVA 返回数据形式为 样式1（JSON结构层次不一样） 接口数目 60个 ， 部门2 使用 .NET 后台，返回数据样式为样式2 （JSON结构层次不一样） 接口数目60个，部门3 使用PHP后台 ，返回数据样式为样式3（JSON结构层次不一样） 接口数目10个，部门4 使用JAVA 返回数据形式为 样式1（JSON结构层次不一样） 接口数目 20个。真是望山跑死马啊，100多个接口挨个找每个部门的人去对接，还有100多个接口要写100多次POST和GET请求，真是累啊，而且很多接口初期定义的不合适，需要修改的吧啦吧啦，可怜只有三个iOS开发对接这个项目，根！本！忙！不！过！来！啊！！！

感谢CCTV给我这么一个提升自己的机会。
思考之后的方法只有一个，那就是批量生成RequestList文件和RequestHeader文件，然后就有了下面这个文章。
iOS填坑之2 - 如何工具化自己的开发之路，如何深入，更加深入

批量生成RequestList和requestHeader文件
世界不大，与君共勉。