从0到1探索淘宝短视频流的架构再设计和工程重构

• 找人：与相关干系人（技术，产品、设计、测试）沟通，对需求进行确认和答疑，深入的了解业务。这个是最有效的手段，可以带上一杯咖啡，找找对应的同学，聊聊业务的前世今生。

• 看文档：看原有的需求文档、设计文档、测试用例、设计稿，帮助我们更好地去理解原有的需求。

• 看代码：根据上述了解到业务功能，从最上层的 UI 页面代码看起，逐步根据代码的调用栈查看相关的逻辑。深入的了解代码。

• 架构的问题：业务当前遇到的问题是什么，对应的业务工程遇到的问题是什么，哪些架构可以解决这些问题。

• 团队的现状：团队当前的规模如何，双端的人员占比多少，团队的技术储备如何，新架构能否在这些方面和团队现状契合。新架构的引入会增加团队同学的理解成本吗。

• 落地的成本：新架构相比老架构落地成本如何，落地路径如何，是一步到位，还是渐进式演进。

• 在架构的问题上

• 业务期望能够摆脱对发版的依赖，需要可以快速的进行迭代。

• 业务工程架构耦合度高。代码质量差。超大类（老架构 1000 行代码以上的类 6 个，其中视频流实例入口类 3000 行）。工程能力弱。没有标准化文档，缺乏工程脚本，新人上手工程难，问题排查手段单一，缺乏有效的线上监控等等。

• 在团队的现状上

• 团队规模逐渐变大，也分了多条业务线，面对耦合的模块，需求改动难度大，代码冲突多。

• 团队需求多，人员紧张，新架构越简单越好，不要引入复杂的架构/技术增加团队成员的理解成本。

• 在落地的成本上

• 工程大，功能多，可以考虑先基于原工程重构，优先搬移大块的代码，解决整体耦合的问题。最后整体搬移到新工程。

• FluidSDK （新架构命名）的基本功能单位是服务 ，每一个独立的功能就是一个服务。例如提供视图组装的容器服务，提供列表管理的列表服务，提供接口请求的数据服务等。

• 服务通过服务注册表进行注册，通过服务注册表管理器进行管理，然后在视频流实例使用。

• 服务通过视频流上下文进行获取，得到对应服务的接口，然后通过接口调用服务的能力。视频流实例实现了上下文接口。每个 TAB 都是一个视频流实例，例如关注/推荐/直播等。视频流实例是各种服务的具体承载者。

• 功能自动化测试：测试同学编写的测试脚本，验证业务的各种功能。

• 稳定性自动化测试：测试同学编写的测试脚本，运行业务的各种功能，以验证程序的稳定性。

• 性能自动化测试：测试同学编写的测试脚本，测试重构后的性能表现。

• 单元测试：开发同学编写的测试用例，从代码角度，验证各个类/函数的功能。单元测试前期成本较高，可酌情按需落地。

• 小步：将整个重构分解为小的步骤，例如一次方法提取，一次方法移动。每一次小的重构后可以通过版本管理工具进行保存，这样方便我们及时将代码进行回滚。

• 频繁运行测试：每当有一次小的重构完成后都需要频繁执行测试，如果这个时候测试有异常，就证明我们的重构破坏了原有的功能，需要进行排查。通过这样的反馈，我们可以在更早期发现问题并及时处理。

• 使用 IDE 的安全重构功能：使用自动化重构可以有效减少人为修改代码带来的风险，并且效率也会更高。

• 提取（Extract）：重构的重用手段，大化小，繁化简，提升代码的可读性。

• 内联（Inline）：独立的函数、变量没有对提升代码可读性有帮助，可以进行消除，内联到对应的调用位置上。

• 封装（Encapsulate）：封装是实现高内聚的有效手段，“对不变的部分进行封装，为变化的部分提供扩展”。

• 重命名（Rename）：函数/变量的重命名有助于提升代码的可读性，如果一个函数/变量无法用一个合适的单词表达，说明这个函数/变量违反了“单一职责”，需要重新进行设计。

• 移动（Move）：移动函数/变量，把负责同一个职责的函数/变量放在一起，提升代码的内聚。

分类	操作子项	子项演示
提取（Extract）	提取函数（Extract Method）：将一段代码提取成一个函数。拆分&精简大函数的常用手段。
	提取变量（Extract Variable）：将一段难以理解的长表达式提取成一个变量，提升代码的可读性。
	提取类（Extract Class）：提取类是拆分超大类的有效手段，按照类责任的划分，将属于一个职责的代码提取到一个类里面去。
	提取超类（Extract SuperClass）：如果发现两个类在做相似的事情，可以把它们相似之处提取成超类，复用该部分代码。
内联（Inline）	内联函数（Inline Method）：内联函数通常用在函数的拆分不合理，先用内联把多个小函数合并成一个大函数，再进行函数拆分和提取。
	内联变量（Inline Variable）：变量并不比表达式更具有表现力，可以直接通过内联消除改变量。
	内联类（Inline Class）：如果一个类不在承担足够的责任，不再有单独存在的理由。可以把通过内联把这个类移除。
封装（Encapsulate）	封装变量（Encapsulate Variable）：对 public 变量进行封装，设置为 private，缩小可见范围，同时严格控制暴露 set 方法。
	封装集合（Encapsulate Collection）：避免外部可以直接访问和修改集合本身，对集合内部数据提供单独的 get 和 put 方法。如果确实需要返回集合对象，考虑使用保护性拷贝，返回集合对象的一个副本。
重命名（Rename）	修改函数声明（Changed Signature）:修改函数声明包括修改函数名字，修改函数参数。一个好名字可以一眼看出函数的用途。合理的函数入参设置，可以降低函数调用者的理解成本。切忌在函数里面堆砌参数。
	变量改名（Rename Variable）:好的命名是整洁编程的核心，变量可以很好的解释一段程序在干什么。
移动（Move）	移动函数（Move Function）：每个函数都有自己的上下文环境，在面向对象语音中，类一般就是函数的上下文环境，如果一个函数频繁的其他类的函数/变量交互，说明它不适合放在这个类里，把它移动到它应该去的类里面去。
	移动变量（Move Field）：和函数类似，变量存在的上下文也是类，一般谁为变量赋值谁就负责管理这个变量。变量的移动一般发生在函数移动之后。
	移除无用代码（Remove Unused Code）:无用代码包括编译期和运行期没有被调用代码，编译期未被调用的代码通过 IDE 就可以安全移除，运行期没有被调用的代码则需要通过代码覆盖率工具进行统计。
	函数/变量上移（Pull Memebers Up）：函数/变量上移是提升代码复用性的有效手段，在处理继承关系时，如果两个子类的两个函数/字段做了同样的事情，可以考虑将其上移。
	函数/变量下移（Pull Memebers Download）：如果父类中的一个函数/变量只和它其中的一个子类有关系，那么这样的函数/变量就需要下移到这个子类中。
	以代理取代继承（Replace extend with Delegate） 继承虽然可以实现代码复用，但是也带来了两个问题： 继承一般只是单继承（只能继承一个类），如果想处理两种不同行为的抽象，继承无法实现。 继承给父类和子类引入了非常紧密的关系，父类的任何改动都可能会影响子类。 因此我们可以把不同行为的抽象委托给代理类（Delegate）去处理。我们平时耳熟能详的“对象组合优于继承”，以及设计模式中的状态（State）模式、策略（Strategy）模式，也有异曲同工之妙。

一套新架构设计并落地后，我们还需要有效的手段守护架构不被后续的修改破坏。这个手段需要落到具体的工具上，单纯的文档规范无法做到这一点。这个时候架构守护 ArchUnit 就派上用场了。

约束	示意图
约束包之间的依赖关系
约束类之间的依赖关系
约束包和类的包含关系
约束类之间的继承关系
约束类的注解
约束层之间的依赖关系
约束循环依赖

• 新架构数据大盘

• 新架构生效率（分钟表/天表）

• 新架构版本大盘（分钟表/天表）

• 新架构错误码大盘（分钟表/天表）

• 新架构性能大盘（分钟表/天表）

• ...

• 稳定性：Java Crash 、ANR 等

• 性能：首帧、帧率、内存等

• 舆情

• 放量到 10% 之前：这个阶段主要观察稳定性数据，有没有 Java Crash，ANR 等。

• 放量到 10% 之后：这个阶段主要观察性能数据、业务数据，有没有线上舆情等。