美文网首页iOS开发实用技术ios 开发iOS开发历程
(iOS)接手旧项目, 看到这样的代码不要哭... 因为你已经在

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

作者: ZeroJ | 来源:发表于2016-09-18 22:18 被阅读3039次
痛苦.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

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

相关文章

网友评论

  • S型身材的猪:对于跨界面传值,我去,真的是被你说中了,我接手的要么是单例,要么是存本地
  • WinterIsHere:最近接手了个项目,到处都是十几个 if else if 嵌套在一起:scream:
  • a1ca31b58342:简直了,楼主说的全中,甚至还有更牛的.拼音和英文加一起,结果拼音开头字母,英文前三字母.以及等等等等.
  • b5d3afef7080:装十三的还是多过说点有营养的,傻逼太多骗子不够用
    ZeroJ:@Fantastic_mj 聪明之人自然会尊重人,有病之人习惯到处乱喷
  • 光彩影:打算用swift3写新项目,网络请求用Alamofire(重点不支持iOS8了)。都想换成AFN 了? 给个建议
    ZeroJ:@光彩影 alamofire自己稍微改一下就能支持swift3.0了,当然,可以换成AFN
  • lym不解释:拒绝通知
  • 点柈:随着敲代码的时间加长,也逐渐意识到自己以前的编码习惯和编码都有问题,在以后的编码中慢慢改正。不过可就辛苦了将来某些要改我代码的人了。哈哈哈,想想心里好惬意,自己改代码的时候也痛苦的一塔死
  • freesan44:关于跨页面传值
    见过有人的项目中所有的跨页面反向传值, 全部使用单例来传递, 然后许多个地方都在修改和获取这个单例对象的同样的属性, 当你接手这样代码的时候, 哭吧... 你根本不知道这个值在那些地方会被修改. 另外有一种恶心的传值, 这种人也是无语了, 需要的跨页面传值统统写入本地文件中, 然后在其他页面直接读取文件中的值... 天才啊


    不然应该怎么做,通篇只是吐槽别人不应该这么做不应该那么做,是否在每一条吐槽里面提供1,2条建议,说说应该怎么做才对?
    freesan44:@ZeroJ 抱歉,通篇我只看到不应该做什么不应该做什么,风格和那些三流朋友圈的营销文一样,起一个引起读者注意的名称,然后在里面无论据无论证直接说论点,一劲说XXX的不是,毫无阅读价值,你这篇文章里面连学习价值都没有,我也看不懂为何CocoaChina会推送这样的文章给我们看
    ZeroJ:@freesan44 这。。看到别人的吐槽都还找不到问题
    ZeroJ:@freesan44 这。。看到别人的吐槽都还找不到问题
  • 三粒黑子球:我觉得不应该一味的抵触别人代码写的不好,有的时候不站在别人的角度想问题,我们会不知道为什么他这么些。有一天,我们代码也可能被别人看的时候,别人也会觉得不好,我们只能让自己改的和自己写的尽力更好,同时也要会包容。
    ZeroJ:@三粒黑子球 这不是抵制和包容的问题,正式项目写成这种代码,说明能力远远不够
  • 水晶可乐Z:通知确实是让人头疼, 无数的通知
    ZeroJ:@水晶可乐Z 除了向多个对象传值,使用通知确实很烦人
  • 整个夏天:用AF的请求,我觉得你直接把AF的接口方法改一下不就行了?
  • 捕梦人:整个项目无一句注释且编排混乱,近视度数指数上升 :pray:
    ZeroJ:@捕梦人 :joy::joy:,有时候当执行到某一行的时候我也会用YES和NO来判断,不过并不是他这样用的,NSAssert(NO,@".......")
    捕梦人:@ZeroJ 可能我太菜,但我想问问以前的那位 if(YES){};是个什么鬼,WTF!!!!
    ZeroJ:@捕梦人 :grin::grin:说的对666
  • 资料库:反向传值不就是用代理或者block或者通知吗。。。。。没啥问题啊,要不然反向传值咋办?
    ZeroJ:@资料库 :smile:,适量,一个协议用来定义一个方法传值未免有点不爽,选用block比较合理,一个class需要写多个block来传值,也许定义一个协议比较好
  • 三十一_iOS:其实有好些更坑,
    看着写了一步步步骤,还有注释,猛一看,
    呦西,不错。。。
    但是!!!!
    麻蛋的写的注释跟代码完全对不上,注释是一个意思,代码又是另外一个意思!!!

    ps:我以前写的一个类6000行。。。最后自己都看不下去了。。
    ZeroJ:@三十一_iOS :smile:,很多人第一次写代码的时候,加了注释,但是后面修改的时候就不改注释,这也是写注释容易忘的地方
  • fd09339b49f0:现在的培训机构导致了很多人都只能叫UIButton工程师,而不是iOS工程师
    无夜之星辰:@甜甜的雨 UILabel工程师路过。。。
    一夜暴富两夜也行:@ZeroJ 这个绝了 UIbutton工程师。。。:+1:
    ZeroJ:@heheda2016 :smile:,估计培训机构都认为iOS开发都是操作一点界面罢了,UIButton也挺好用,其他的全有第三方库
  • c93d5c7594f4:我是新人,有个问题,反向传值的合理做法是怎样的?
    Maj_sunshine:@CoderLXWang 兄弟 很赞同你的观点
    CoderLXWang: @jelwell 一对多,a界面某个操作,bcd甚至ef界面都要有反应就通知。。。点对点,但是方法比较多,就用协议,这样更规范。。。只有一两个位置,也没啥复杂的就用block。。。整个工程中只有一个的东西可以用单例,比如个人资料这种,万一很多地方都用,单例最方便
    ZeroJ:@jelwell block,代理,通知,都可以用来反向传值,使用清晰就好,不过更多的人喜欢block ,简洁而且代码聚合高
  • 多加辣椒:前不久接手一份外包出去的项目,那叫一个烂啊,坚持改了一个多礼拜,实在无力,推翻重写了
    ZeroJ:@歪樣 :smile:,这种确实是水平可怕啊
    多加辣椒:@ZeroJ 公司被外包团队坑了,准备拿回来大改版,与其改代码还不如推翻重做,我觉得最可笑的是原项目中的cell基本都是用alloc init 方式创建,下面就是一堆创建UI的代码,一个代理方法挤着几百行的代码,现在回想起来都后怕:sweat_smile:
    ZeroJ:@歪樣 :smiley: 还能够重写的项目(应该不是很大), 都能被人写成这样 :relieved:
  • Charles___:这吐槽 无敌 哈哈…
    Charles___:@ZeroJ 早遇到了…
    ZeroJ:@一只孤独的iOS 😆你也会遇到的
  • 若雨千寻:我的代码就是这么写的,没办法啊,MRC就我一个菜鸟==
    ZeroJ:@若雨千寻 那就玩转吧
    若雨千寻:@ZeroJ 嗯,主要我是菜鸟mrc没玩转 :smiley:
    ZeroJ:@f3ab5e4efb59 其实这个和是否MRC没有太多关系,代码习惯不好的话,到后面可能自己就看不懂了
  • f1e24a8d40b9:我现在写代码都尽可能标上注释 方法是干什么的注释在上面 变量也加上注释 哪怕是用得比较少的BOOL值我也加上去 因为我已经受够了顺着方法名一步步点击才能找到下一步在哪 按control+f搜索一个变量看半天才知道那个变量是干什么的这种恶心的事了 我觉得比较好的代码就是有完善的注释 让别人知道你的那个方法是干嘛的 哪怕一两个字 变量注释好 代码格式用clang format格式整齐一点就可以了 哪怕你逻辑很烂 我也改得顺心一点
    ZeroJ:@嘸___ 嗯,好习惯,注释很友好
  • ebay_Happy:说了半天都是废话,谁还不遇个坎坷了,坚持就过去了
    ZeroJ:@beast文强 :smiley: 没办法啊, 我个人开发能力没有朋友你的水平高, 只能吐槽
  • HoyaWhite:我就是那个写让你们哭的代码的人
    HoyaWhite:@ZeroJ 哈哈
    ZeroJ:@WhitePlimsolls :smile: 不不不, 一般这么写的人都不会意识到有问题的
  • noonez:关键教他们还不听,最后自己都写不下去了,就吵着改需求,真操蛋!
    ZeroJ:@枫三十 :smile: 对啊, 这是真的, 都只会怪需求更改太快
  • macfai:一男,精辟啊
    ZeroJ:@macfai 😆, 那你比较舒服, 最近,我写了四十多页了😆😆
    macfai:好吧,改别人的代码是最痛苦了,最近做了个新项目,稍微好点
    ZeroJ:@macfai 😆, 最近看几个项目的代码都要哭了, 见过一个定义常量的文件里面定义几千个的没?? 心都碎了
  • 今天中午吃什么:看到最后,有个疑问,用runtime来写侧滑手势返回不是常规写法吗?那应该怎么写呢?
    DreamBuddy:凡事把握好度。。
    今天中午吃什么:@ZeroJ 恩恩。确实奥 :blush:
    ZeroJ:@今天中午吃什么 很多情况确实是这样解决的,但是,当遇到手势冲突的时候处理起来就比较麻烦了,而且还不好定位问题,如果要处理全屏返回的功能,建议使用系统的自定义转场动画来实现,自定义程度大,也方便解决会遇到的冲突问题
  • zhq1992:示范一下正确的代码就更好了
    ZeroJ:@周焕强 :smile::smile:,能力有限,不敢示范

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

本文链接:https://www.haomeiwen.com/subject/pcsgettx.html