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

最近在针对视频落地页做一系列的代码重构。工作之余，又把之前的《重构：改善代码的既有设计》复习了一下。有了一些新的感悟和想法。故而有了这一系列的文章。规划的是讲一讲自己在项目中的心路思考及对重构的新认识。

0x01.重构原因

因为历史原因，小视频落地页几个主要的类代码都在3500行-4000行之间：

Large Class带来的问题和风险是多样的：更低的代码可维护性、更低的代码可读性、大量的成员变量、冗余重复的代码、因为实验负向下线的不再使用的代码，随着版本迭代，这些都会造成类的膨胀，随便一个落地页的需求，大家都会往这三个类里塞代码，最终代码的可维护性会越来越低。

短视频落地页需求。短视频落地页这个需求也推动了我们去做这次重构。

在小视频落地页落地一些研发需求越来越困难，举一个简单的栗子，recycleview的复用回收机制显然是比viewpager要优秀很多的，目前的落地页在低端机上滑动卡顿比较明显，但是当我们尝试把滑动组件从viewpager切换到recycleview的时候，发现因为大量的业务逻辑和埋点逻辑，基本不太可能，Large Class承载了太多职责，散落各处的业务逻辑、打点逻辑，也让我们在推动技术需求落地的时候举步维艰。
….
基于以上的背景，落地页的重构很有必要。

0x02.重构目的

提升代码的可读性和可维护性
为后续增加新的功能铺路

0x03.重构一期

重构一期主要做了三件事：

1. 根据功能将XXXHolder的职责拆分到不同的block中去
2. 对XXXManager请求做重构，支持短视频和小视频两套请求
3. 整理落地页包结构

我们来看下简易架构调整：
旧版：

重构后：

我们对比前后发现，XXXHolder代码拆出来了1500多行，这只是一个最直观的感受。这件事情的长期收益是，建立了落地页功能的边界，如果下次开发一个互动区的需求，在以前RD会直接在XXXHolder里继续增加代码，但是重构后，RD会在相应的XXXLeafingLayout中去增加代码，这样不仅不会继续加重XXXHolder的职责，反而可以把互动区的职责很好的封装起来，如果我新写一个holder也需要互动区的功能，我不需要copy XXXHolder里2000多行的代码，只需要引用一下XXXlLeafingLayout就可以了，让block具备了一定的复用能力。

0x04.如何控制风险？

重构，肯定都有一定的风险，但是考虑到长期收益，还是要做重构的事情。
所以针对重构，对风险如何把控呢？

1. 循序渐进的重构，不要想着一口气吃个胖子，逐步重构，逐步自测，逐步验证，保证风险可控；
2. 在重构过程中要记录好影响的功能和部分，提交给QA重点验证；
3. 如果有单元测试，就更好了
4. 保证充分的自测，充分的暴露问题给QA

0x05.遗留问题

一期重构后，我们发现，还有一些问题是没有解决掉的，比如：

1. XXXAdapter代码已经增加到4000多行
2. entity在落地页各个类中传来传去，被改来改去，里面的landdetail是在另外一个接口返回时才有值，此外，因为各种业务逻辑，entity 里面有大量的控制变量
3. 仍有部分下线的实验代码充斥在项目的角角落落里
4. …

以上的我们可以在重构二期中去解决