[iOS] 接手旧项目，看到这样的代码不要哭 ... 因为你已经在这里见过-CSDN博客

做iOS开发, 难免会接手别人碰过的代码, 之前做过一些外包项目, 是别人已经完成了前期的功能, 然后到我这里就需要接着之前的任务继续开发, 相信很多在上班的朋友也一样, 总是会接着写别人的代码, 然后每次, 我相信你肯定会和我一样, 看着看着, 心中一万条草泥马~~~飘过, 然后不得不默默的填坑. 当然你写的代码同样的以后可能会被其他人看到, 所以我每次看到以下几种类似的代码, 必定会痛骂一番, 如果你希望你写的代码以后少被人骂, 至少不要写出下面的代码吧... 前方高能~~~

项目中到处引用第三方库-- 比如 AFN 我们在项目中, 肯定不可避免的会使用到第三方库. 第三方的开源贡献者为我们做了很多的工作了, 感谢他们吧. 但是使用第三方库带来的另外一点小的隐患就是, 可能随着项目的开发我们会遇到更换第三方库的需求, 那么如果你之前整个项目到处都依赖(引入第三方库)第三方库的话, 对于更换第三方库的代价就是巨大的. 最常见的是项目中的网络请求使用AFN来完成, 你说使用这个第三方库来完成网络请求肯定是比较正确的选择吧, 但是...... 网络请求基本上就 发送,GET,POST请求, 下载文件, 上传文件 这么四个常见的需求, 你使用AFN难道就不能自己封装几个接口出来, 然后项目中的网络请求都使用自己封装的这几个接口, 以后在更换网络请求库的时候直接更改这几个接口不就好了, 而不需要再所有项目中用到网络请求的地方都挨着挨着改一遍(基本是没办法改的, 不是到现在为止很多项目还使用着ASIHTTPRequest么),我见过整个项目使用swift来开发的, 然后网络请求库使用的是AFN, 项目中所有的网络请求都是直接使用AFN的接口来完成的, 结果后来项目决定需要更换为Alamofire, 然后... 你懂的

@interface ZJHttpTool : NSObject
/**
 *  发送一个GET请求
 *
 *  @param url     请求路径
 *  @param params  请求参数
 *  @param success 请求成功后的回调（请将请求成功后想做的事情写到这个block中）
 *  @param failure 请求失败后的回调（请将请求失败后想做的事情写到这个block中）
 */
+ (void)get:(NSString *)url params:(NSDictionary *)params success:(void (^)(id responseObj))success failure:(void (^)(NSError *error))failure;
+ (void)post:(NSString *)url params:(NSDictionary *)params success:(void (^)(id responseObj))success failure:(void (^)(NSError *error))failure;
...
@end复制代码

命名规范听说过OC中类命名要加前缀吗? 嗯随手一写, 习惯了自己每个项目中都定义一个全局的常量文件命名为constant.h吧... 能不能加个类前缀, 虽然这种对项目中整体的影响不大(冲突了会报错, 你总会修改了吧), 但是这种不符合规则的类命名真的让人很不爽听说过变量名使用英文变量命名吗? 你说这个计算机的世界是英语的世界都是事实, 大家都提倡变量命名使用英文来命名. 所以那些使用拼音来命名的爱国者是怎么想的, 见过一大堆的youxiangzhanghao, banjibianhao, xingmin, xingbie ..., 你说这些常见的名词的英文你写个拼音真是让人无法直视啊, 只能让我开骂---一定是个英语弱爆了的傻X写的代码... 好吧还有一种人是这样的, 真是严格遵守命名规范, 于是项目中的变量名都使用英文的, 不过啊不过啊, 对于我这种六级飘过的学渣而言, 看你们这些大神高级的命名全靠词典啊, (电脑常备有道没有错) anticoagulant (抗凝剂), tranquilizer(镇定剂)... 总之一堆一堆的药名和专业名词 这些东西简直不能忍啊, 看代码就是查字典去了, 这里我希望用拼音, 哪怕别人骂我是用拼音的傻逼...
代码量多到难以阅读的class文件这个真的是遇到的非常非常多的了, 一个controller打开, 见过最多的接近4000行, 我的天, 这让人怎么活, 最坑爹的是, 横下心去看看---- 一个viewDidLoad里面2000多行代码...... 只看到大括号开头啊还有人项目中将使用到的常量放在一个文件中来管理是个好习惯, 但是, 你这一个文件中放了几千个常量... 真的是欲哭无泪啊...
到处都是通知 iOS开发中, 通知真的很好用啊, 跨界面传值, 同时可以传值给多个对象. 但是, 也不带这样来使用的啊, 所有的页面反向传值, 感觉通知最方便了, 一个post就发布一条通知, 然后项目中到处注册通知来监听, 不知道这些人是怎么做到的正确的移除通知监听者... 更无语的是, 发布的通知的命名那都是随手一写... 通知虽然好用, 但要注意使用的场所啊
到处都是神奇数字项目中见过到处都是的, 最常见的是在设置frame的时候, 也许正如注释的那样, 所有的数字都是这位开发者, 写代码的时候感觉这些数字比较合理
```
  // 高度为44看上去更合适
  self.searchBar.frame = CGRectMake(0, 22, 320, 44);复制代码
```
到处都是代理上面刚说了有人到处使用通知的, 这里也有人到处使用代理的, 凡是需要反向传值或者响应某些操作的, 通通先写一个协议, 然后实现一个代理, 我有见过一个头文件上面遵守十多个协议的, 然后这些协议里面基本上只有一个代理方法, 还有一种更可恶的是, 一个协议包含很多很多的代理方法, 全部标记为optional ..., 然后在需要的地方直接调用

像这种, 在controller中遵守了许多个协议, 很多方法都不知道是那些协议里面的, 至少你也要加个注释什么的吧 ... 
- (void)saveBtnDidTouched {
    // 代理一...
}
- (void)sexDidChanged {
    //代理二...
}
- (void)downloadDidFinished  {
    //代理三...
}复制代码

随便引用第三方库-- 然后自己修改其中的一些地方, 这个时候你还敢不敢pod update
关于跨页面传值见过有人的项目中所有的跨页面反向传值, 全部使用单例来传递, 然后许多个地方都在修改和获取这个单例对象的同样的属性, 当你接手这样代码的时候, 哭吧... 你根本不知道这个值在那些地方会被修改. 另外有一种恶心的传值, 这种人也是无语了, 需要的跨页面传值统统写入本地文件中, 然后在其他页面直接读取文件中的值... 天才啊
一个class实现很多个页面的功能有些人代码复用的观念真的是太强了, 不想多写一点代码, 于是, 一个自定义的UITableViewCell里面各种判断, 来实现很多的控件的隐藏和位置调整... 明明看上去不是很像的各种cell, 硬是被他放到了同一个cell文件里面来管理...
尽全力使用黑魔法到处+load 这种人, 不知道是为了显示自己多有学问还是什么, 项目中一有机会, 直接写个系统类的扩展, 然后重写+load方法, 继续高能, 使用黑魔法交换系统的方法... 当你发现自己明明是继承自系统的控件来写的代码, 为什么为什么, 效果很是古怪, 然后你就开始怀疑人生了. 我曾经在一个项目中使用UINavigationController的时候, 因为自定义了返回按钮, 然后侧滑手势失效了, 于是像以前那样解决, 更改手势的代理(具体方法百度吧),发现不管怎样都不会向以前那样有效, 最终很长时间的检查才发现, 在以前的某个文件中有人使用runtime更改了手势的代理, 用于实现全屏滑动返回的效果...