8762bfcd50e35c7532f4d01e7d2fef5b
重构你让我身心疲惫

前言

最近已经很久没有写技术文章了,主要是最近需要重构的项目时间太紧促了。再加上回到家之后累的就不想摸电脑,就一直没有写文章了。

最近一段时间总算是松了一口气下来,需求做完了,开始了测试阶段。

项目重构

说是项目重构,其实也不完全是重构。因为涉及到 UI 重构的只是一部分,大部分都是逻辑上面的重构。

关于这次重构,我并不觉得是公司项目为了后期维护着想,我觉得大部分的因素还是领导还是想在公司有些业绩站立脚跟吧。

我们之前的老接口是基于 PHP 开发的,确实维护起来十分的困难。里面有大量的判断是 iOS 还是 Android 的判断逻辑,很容易造成后期很难维护。

但是针对重构也是漫长的一个过程,需要不断测试之后在测试才能进行上线替换。

但是我们的万万没想到,就一个月的时间。而且 APP 端也是最繁琐的任务,并且 iOS 是最复杂的工作。

如果只是重做不做灰度发布功能的话,我们的工作量至少也没有现在这么多。

当时出了几个方案,我们主张的时候后台PHP 端不管 JAVA 什么字段,封装之前的老字段返回即可。

这样只用在 PHP 边进行 JAVA 接口大数据测试,真的有问题 PHP 再切回去老接口即可。

但是对于公司宝贝儿子 PHP 来说,能让别人多干自己就少干些。

说到这里,我想到之前在《中国合伙人》黄教主这样说过一个感人啼笑的故事。故事讲述他在大学一直帮助一个女生打热水,这个女生对他不冷不热。

最后他才发现这个女生是有男朋友,只是不想累到自己男朋友而已。

我觉得我们目前在公司的角色位于这个故事一直打热水的小伙,功劳没有,工作都是自己的。

最后决定我们 APP 做灰度发布功能。

灰度发布功能

这个灰度发布功能主要是根据用户所在的区域,是否开启 SOA 新接口。如果开启就用 SOA 新接口,如果没有就用老接口。

关键这个灰度发布功能只测试一个月,一个月之后就会开启全量。

意思我们所做的努力只不过属于一个月的过渡期的产物而已。

针对灰度发布功能,主要涉及到一些功能点。

  • 是否公用一个 AppDelegate 入口
  • 老版本代码和新版本代码合并会不会出现很多编译错误
  • 合并之后互相切换本地序列化的类会不会抱错
  • 两个版本合并之后分类会不会出现絮乱调用
  • 第三方能否公用一套
  • 一些第三方统计等怎么区分
  • 灰度发布之后怎么移除老版本

这是当时我们进行项目危险度评估一些关键点评估,对于我们都是一个未知数,不知道会不会遇到问题解决不了,就中断了过程。

本来我主张 PHP 可以让风险降低在最低,也会很快的度过这个灰度发布期。最后在公司的压力之下,我们只好妥协。

我当时也在Swift 开发者大会的大群问过很多大神,没有人遇到过我们类似的需求和任务。基本上没有任何的帮助,剩下的只有自己探索而已。

对于我们来说,这个想法理论上是可以实现的,但是中间会遇到怎么的荆棘,谁也不知道。我们的项目还是用运行时语法 OC,这样更增加危险程度。

对于 M 和 WEB 他们只需要连接重定向就可以把老用户转到新的重构版本,他们的工作只需要放在重构的任务当众。

但是 APP,我们难道也让 APP 安装两个版本的 APP,让用户切换到新的 APP 上吗。这个方案明显不行,那么唯一能做的就是合并两个版本在一起发布。

这个对于安卓也没十分的难度,那就是分包即可互不影响。但是对于我们来说,只有 Swift 才有包概念。对于 OC,除非打包成 Framework 才可以。

唯一可行方案,用前缀进行区分。

  • 类名称添加前缀
  • 文件名称
  • C 语言的方法
  • 分类的方法
  • 枚举
  • 常量

如果之前这些都加上前缀,我们复制一份,更改一下前缀即可。可是,可是,我们的项目经过的手比较多,在我接手之后,经历一次代码规范。

后期的前缀十分规范,但是之前遗留的老代码依然是没有前缀。

利用前缀融合两个包这个概念在我们团队里面算是达成共识,也不会更改了。

在什么时候启动切换

之前 PM 考虑到在启动时候就获取是否启用新接口,然后就走新接口。

因为在 Main 函数里面是无法同步请求的,那么只能公用一个 AppDelegate 类。

top Created with Sketch.