说说重构那些小事二：小视频落地页重构二期

0x01.二期的主要目的

二期主要是为了解决DetailAdapter代码膨胀的问题。目前DetailAdapter代码量已经达到了4300行。里面充斥了网络请求、业务逻辑、埋点逻辑、弹窗逻辑等等。在最小化对功能的影响的前提下（因为落地页有很多关键指标的埋点，包括商品浮层、播放loading率、起播时间等等），我们都是期待尽量少的动到过去的业务逻辑，其实之前尝试过做简单的重构，不过更多是把大的方法块分割成多个小的方法。其实作用微乎其微。

所以二期的主要目标是：

更小的类
更少的代码
更少的耦合
删除实验代码

怎么最大化的减少代码量。看了下《重构》，对应的是3.3过大的类。书中给出的药方是：extract class和extract subclass两个方法。并且提到如果你的large class是个GUI类，你可能需要把数据和行为移到一个独立的领域对象中。

那这里我们可以确定，需要做的大策略就是：抽取类出来。

那怎么去抽取类呢？我自己简单的做了个头脑风暴，把一些想法罗列了一下：

大家可以看到，我的头脑风暴是比较凌乱的，只是几个关键字，其中也有一些目前来看无效无意义的想法，但是头脑风暴就是这样的，帮你搜集自己的过往的思路来应对这个问题。

仔细梳理一下后，在Android上我们可能旧需要对架构做一定的调整了。最终我选择使用MVP来简要重构一下DetailAdapter。

大方向有了，下面就是执行了。

下面是我的几次架构调整的简单的草稿图：

0x02.探索方案1：activity作为v层，adapter作为转发

看图说话：这个调整，我们把activity作为V层，抽出来了一些接口方法，P层主要处理网络请求，处理各种manager。这次调整，我们把activity中的数据处理和网络请求移动到了presenter中去，同时也把adapter中的大量的数据处理和网络请求也移动到了presenter中去。

这样的改动会有个问题：

改动很大，影响面很大
因为adapter中的网络请求和逻辑更多，但是v层接口设置在activity，所以presenter中关于adapter部分的逻辑，回调到activity中的接口的时候，很多方法体只是针对adapter做了一层转发、

在以往的项目经历里，MVP的场景里，adapter层其实没那么厚，adapter中不会出现那么多的网络请求等等。之前还没遇到过这么厚的adapter层。比较常规的写法如下：
使用MVP来实现recyclerview数据
https://blog.csdn.net/qq_39914866/article/details/78513810
可以看到，实际上adapter层应该很薄，直接是activity层处理好数据之后转发进去

基于这个问题，我专门去网上查了下相关资料，在MVP里，Adapter怎么处理。多数资料告诉我：adapter其实就是presenter。但是基于目前的现状来看，显然不适用我当下的场景。

直到了看了下面这篇文章：
MVP中对adapter的一次修改
https://zhuanlan.zhihu.com/p/21427751

文中提到adapter可以作为V层的。所以有了下面的计划，计划设置两个v层接口，activity的和adapter的。

0x03.探索方案3：两个v层，activity和adapter两个v层

这个是调整之后的架构。我们可以看到activity和adapter都依赖了presenter，且activity和adapter之间的双向依赖没有了。

不过，表面看，这个架构是比较好的调整。但是因为改动实在是太大，到后期，已经不可控了。所以这个改动最终被我revert了。

0x04.最终方案4：还是一个V层，adapter作为V层

这个图里面，我们可以看到改动就比较小了，不过看着有点别扭，不像平常的MVP架构。做到了，保证少量且清晰的改动

但是这也是折中和妥协的方案，受限于测试等等，重构肯定不可能完全完美的。

我记得，之前有个朋友说，他们公司的MVP太难用了，同事都吐槽。其实现在想想，可能在很多技术都是受限于它所在的时代，是有一定历史原因的，所以重构也是，不是照办，而是因事因地制宜，因为受限于旧的代码逻辑，所以不可能，一下子就用最完美最新的技术方案重写一遍。所以重构是基于现状的创造，而不是生搬硬套。

此外，我们阅读代码发现，分享相关的逻辑足足有800-900行代码，我们通过extract class的方式，我们又抽取了一个分享的管理类，提炼出来了900多行代码。

大层面的调整结束后，我们又做了很多微小的重构，更多运用的都是《重构》里提到的一些方法，比如简化函数调用，重新组织函数，在对象之间搬移特性等等。基本上又迁移出来了一部分代码。

方法的归属
降低对presenter的耦合
一个变量那种直接public取用即可,可以减少方法数
入口初始化代码内聚，不对外暴露了
多增加adapter和presenter的空判断，空指针判断
删除一些冗余的代码
能移动到工具方法里的移动到工具方法里
专门写个dialogutils类吧，太多dialog了
迁移出来未迁移出来的部分网络请求
所有网络请求回调的地方都要重新做判断是finish了
…

0x05.总结

以上是二期目前做的事情，主要概括一下：

MVC - MVP
抽取分享管理类
落地小的重构点

最终我们把adapter中的代码量从4300行控制到了2200行。且需要QA check的点甚至比重构一期还要少。