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

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

0x01.重构原因

因为历史原因&＃xff0c;小视频落地页几个主要的类代码都在3500行-4000行之间&＃xff1a;

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

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

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

0x02.重构目的

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

0x03.重构一期

重构一期主要做了三件事&＃xff1a;

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

我们来看下简易架构调整&＃xff1a;
旧版&＃xff1a;

重构后&＃xff1a;

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

0x04.如何控制风险&＃xff1f;

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

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

0x05.遗留问题

一期重构后&＃xff0c;我们发现&＃xff0c;还有一些问题是没有解决掉的&＃xff0c;比如&＃xff1a;

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

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