[iOS] 接手旧项目,看到这样的代码不要哭 ... 由于你已经在这里见过

作iOS开发, 不免会接手别人碰过的代码, 以前作过一些外包项目, 是别人已经完成了前期的功能, 而后到我这里就须要接着以前的任务继续开发, 相信不少在上班的朋友也同样, 老是会接着写别人的代码, 而后每次, 我相信你确定会和我同样, 看着看着, 心中一万条草泥马~~~飘过, 而后不得不默默的填坑. 固然你写的代码一样的之后可能会被其余人看到, 因此我每次看到如下几种相似的代码, 一定会痛骂一番, 若是你但愿你写的代码之后少被人骂, 至少不要写出下面的代码吧... 前方高能~~~swift

  • 项目中处处引用第三方库-- 好比 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更改了手势的代理, 用于实现全屏滑动返回的效果...

拒绝

原本是用来吐槽最近见到的奇葩代码的, 不过写着写着就不想继续吐槽了, 反正最终仍是要继续填坑, 不过, 但愿你不会再写出这么诡异的代码出来了, 由于-----真的是会被骂的网络

相关文章
相关标签/搜索