(iOS)接手旧项目, 看到这样的代码不要哭... 因为你已经在

痛苦.jpg

做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更改了手势的代理, 用于实现全屏滑动返回的效果...

拒绝.jpg

本来是用来吐槽最近见到的奇葩代码的, 不过写着写着就不想继续吐槽了, 反正最终还是要继续填坑, 不过, 希望你不会再写出这么诡异的代码出来了, 因为-----真的是会被骂的