前言：
最近一直在维护老的项目，遇到的问题也千奇百怪，需要修补的，需要优化的，需要特殊处理的，感觉总是那么的无语。也许这时候也应该感叹一句：路漫漫其修远兮，吾将上下而求索吧。
这篇文章就只是讲讲老项目中遇到的种种不敢苟同的代码写法，以及遇到一些问题时的处理方法。
1、关于按钮事件的重复点击问题
我们开发中大概都经历过这样的事情，我的一个button被重复的快速点击，（我们开发者应该更清楚的知道这意味着什么）。那我们再深入的想一下（给这样的事件安排一个特定的环境）：例如当网络较差的情况下，再例如当button的执行事件较为耗时时。这时就会出现很多的问题：有时是界面出现问题（当button执行事件中出现调节界面frame的时候）；有时则会出现卡顿，更甚至会出现崩溃现象。对于这种问题，我们要提前考虑到，做好防范处理：即点击按钮事件时：添加防止重复点击功能。
思路是：防止按钮重复点击
原理是：我们每次点击按钮时，先执行取消之前的按钮点击执行事件，然后再去执行一个延迟执行方法（方法中执行的是按钮执行的事件）。
比较推荐的解决方法代码：
- (void)btnClicked:(id)sender { //在这里做按钮的想做的事情。 } - (void)buttonClicked:(id)sender { //先将未到时间执行前的任务取消。 [[self class] cancelPreviousPerformRequestsWithTarget:self selector:@selector(btnClicked:)object:sender]; [self performSelector:@selector(btnClicked:)withObject:sender afterDelay:0.2f]; }
还有一种方法也是可以实现的：具体的看《iOS之防止用户重复点击Button（按钮）问题 》
2、很多界面共用一个界面时：使用枚举做类型判断
老的项目中会出现很多这样的现象：很多界面重复使用一个界面，这样就自然而然的需要在不同的界面跳转到复用的界面时去做判断。而奇怪的地方在于：判断的依据是self.title。那么就会出现这样一种现象：在跳转界面后会有一大段if去判断字符串是否等于self.title 。
如果我们做一些改变：使用枚举来做界面类型的判断，使用switch case语句做判断执行代码。这样会不会更优美，简洁一些。
3、关于老项目中iOS10以上的情况下，导航栏中按钮不显示问题
如果你的viewController都继承于基类，那么在基类中添加这样一段代码（这也是目前我发现的最省事的方法）：
- (void)viewWillAppear:(BOOL)animated { [super viewWillAppear:animated]; [self.navigationController setNavigationBarHidden:YES animated:NO]; [self.navigationController setNavigationBarHidden:NO animated:NO]; } -(void)viewWillDisappear:(BOOL)animated { [super viewWillDisappear:animated]; [self.navigationController setNavigationBarHidden:YES animated:NO]; [self.navigationController setNavigationBarHidden:NO animated:NO]; }
4、事件方法要每个界面区分开
老项目中会有这种情况：在本界面 command点击一个button执行事件方法或者手势事件方法时，会莫名其妙的跳转到另外一个界面。
我们在开发时最好给不同界面button的clicked事件命名是区分开来，例如：界面名+ButtonClicked
5、在开发中如果存在image为空，或者必须显示的String为空，记得在代码中作判断，图片可以直接设置默认图片，字符串也可以设置默认字符串
例如：
UIImage *image = [UIImage imageNamed:@"image"]; UIImage *defaultImage = [UIImage imageNamed:@"defaultImage"]; UIImageView *imageView = [[UIImageView alloc]initWithImage:image==nil ? image:defaultImage];
6、一个界面多网络请求问题，而且需要多个请求都完成后，对界面有一些操作
这是一个老的话题了，我之所以重新提及这个话题，原因是我从一些文章中发现了一个从来没使用过的方法，这个下面会提到，现在就让我们列举出来比较常用的方法。就以一个界面两个网络请求为例 A和B
1、两个请求互套)(也是最笨的方法)
具体是这样的，我在A请求成功后，再请求B。当然如果请求多的话，这个肯定是作废的。
2、使用GCD中的通知
dispatch_group_t serviceGroup = dispatch_group_create(); // 开始第一个网络请求 servicedispatch_group_enter(serviceGroup); [self.configService startWithCompletion:^(ConfigResponse *results, NSError* error) { //请求成功后的操作 configError = error; dispatch_group_leave(serviceGroup);//完成后离开分组 }]; // 开始第二个请求 dispatch_group_enter(serviceGroup); [self.preferenceService startWithCompletion:^(PreferenceResponse *results, NSError* error) { //请求成功后的操作 preferenceError = error; dispatch_group_leave(serviceGroup);//完成后离开分组 }]; dispatch_group_notify(serviceGroup,dispatch_get_main_queue(),^{ // Assess any errors NSError *overallError = nil; if (configError || preferenceError) { // 判断时候请求有失败 overallError = configError ?: preferenceError; } // 最后完成后执行的block completion(overallError); });
3、利用GCD中的信号量
在GCD中有三个函数是semaphore的操作，分别是：
dispatch_semaphore_create 创建一个semaphore
dispatch_semaphore_signal 发送一个信号
dispatch_semaphore_wait 等待信号
简单的介绍一下这三个函数，第一个函数有一个整形的参数，我们可以理解为信号的总量，dispatch_semaphore_signal是发送一个信号，自然会让信号总量加1，dispatch_semaphore_wait等待信号，当信号总量少于0的时候就会一直等待，否则就可以正常的执行，并让信号总量-1，根据这样的原理，我们便可以快速的创建一个并发控制来同步任务和有限资源访问控制。
利用这样的机制，当信号量达到我们网络请求的数量时，请求结束。
4、这个也是我上面说的无意中看到的一个方法，仅拿出来作为参考
dispatch_async(concurrent_queue, ^{ NSLog(@"---并发任务1---"); }); dispatch_async(concurrent_queue, ^{ NSLog(@"---并发任务2---"); }); dispatch_barrier_async(concurrent_queue, ^{ dispatch_async(dispatch_get_main_queue(), ^{ NSLog(@"---所有并发任务结束后回到主线程刷新---"); }); });
以上就是关于一界面多请求的不同解决方案。
7、代码规范问题
【1】为什么这个普通的话题放到最后呢，大概是因为我觉得这个很重要的问题吧，毕竟技术水平不高，还是可以提升的。但代码不规范的话，养成习惯后很难改的，我见过太多项目中使用【拼音命名、不注意驼峰命名法、define预处理指令满天飞等等的代码】这些出现在项目中就像时时刻刻在提醒你，看这样的项目是一种煎熬。
【2】其实代码规范不仅仅是公司对开发者的要求,也是开发者对自己的一个要求。因为如果统一每个人的写作规范，是一件耗时，耗材的事情。小一些的公司是做不来，中型的公司大多是不想做。而大型的公司总是花费近几个月的时间去培养员工的代码规范，这就是财大气粗吧。而且开发者本身对于技术的提升、追求等，都无形中要求自己注意代码规范问题。
【3】对于这部分，建议看看《Effective Objective-C 2.0》这本书，其中起到的。