随着视频流业务的发展，业务的复杂性越来越高，视频流老工程在架构设计、代码质量、工程能力等方面的问题也逐渐凸显。在这样的背景下我们开启了一次对老工程的大型重构。
本次重构是一次对大型业务工程进行架构再设计和重构的探索，本文是对这次探索的一次梳理与总结。限于篇幅，文章总共分为理论篇和实践篇两个部分。
思维导图如下所示：
本文是实践篇，讲述如何从 0 到 1 对一个大型的业务工程开展重构。我们将按照定义架构解决的问题、设计架构的实现方式、重构前的准备、开始重构代码、新架构灰度放量的顺序来进行讲述，让我们开启重构之旅吧！
定义架构解决的问题
在设计新架构之前，我们需要先充分的了解业务以及业务背后的架构设计和实现，这个过程我们不仅要深入的去看代码，更重要的是和关联的业务同学和技术同学进行不断地对焦，向业务同学了解业务背景，向技术同学了解架构设计意图以及技术开发痛点。
我们可以通过以下方式加深我们的现有业务和工程的理解：
- 找人：与相关干系人（技术，产品、设计、测试）沟通，对需求进行确认和答疑，深入的了解业务。这个是最有效的手段，可以带上一杯咖啡，找找对应的同学，聊聊业务的前世今生。
- 看文档：看原有的需求文档、设计文档、测试用例、设计稿，帮助我们更好地去理解原有的需求。
- 看代码：根据上述了解到业务功能，从最上层的 UI 页面代码看起，逐步根据代码的调用栈查看相关的逻辑。深入的了解代码。
在设计新架构的时候，我们需要考虑以下三个方面的问题。
- 架构的问题：业务当前遇到的问题是什么，对应的业务工程遇到的问题是什么，哪些架构可以解决这些问题。
- 团队的现状：团队当前的规模如何，双端的人员占比多少，团队的技术储备如何，新架构能否在这些方面和团队现状契合。新架构的引入会增加团队同学的理解成本吗。
- 落地的成本：新架构相比老架构落地成本如何，落地路径如何，是一步到位，还是渐进式演进。
对于当前的淘宝短视频业务来说，
- 在架构的问题上
- 业务期望能够摆脱对发版的依赖，需要可以快速地进行迭代。
- 业务工程架构耦合度高；代码质量差；超大类（老架构1000行代码以上的类6个，其中视频流实例入口类3000行）；工程能力弱；没有标准化文档，缺乏工程脚本，新人上手工程难；问题排查手段单一；缺乏有效的线上监控等等。
- 在团队的现状上
- 团队规模逐渐变大，也分了多条业务线，面对耦合的模块，需求改动难度大，代码冲突多。
- 团队需求多，人员紧张，新架构越简单越好，不要引入复杂的架构/技术增加团队成员的理解成本。
- 在落地的成本上
- 工程大，功能多，可以考虑先基于原工程重构，优先搬移大块的代码，解决整体耦合的问题。最后整体搬移到新工程。
基于上述的问题，我们定义出了新架构要解决的核心问题：”架构解耦&快速迭代“。
设计架构的实现方式
在「定义架构解决的问题」章节中，我们定义了新架构要解决的核心问题：”架构解耦&快速迭代“。为此我们的架构需要向组件化架构演进，并且支持动态化发布。
在具体落地方案上我们采用了“纵向分层” + “横向模块化（微服务）”的方式。
纵向分层：代码分为业务层（面向业务需求）、框架层（面向容器功能）和基础层（面向基础代码）。核心解决架构代码和业务代码耦合，框架层无法独立于业务进行迭代，无法跨业务复用等问题。
横向模块化（微服务）：每个模块都是一个服务，一个服务的代码都在一个包下面，对外通过接口提供功能，核心解决不同功能之间的代码相互耦合，内聚性差，日常代码推送冲突率高，功能迭代和下线困难等问题。
“三句话理解新架构的实现机制”
- FluidSDK（新架构命名）的基本功能单位是服务，每一个独立的功能就是一个服务。例如提供视图组装的容器服务，提供列表管理的列表服务，提供接口请求的数据服务等。
- 服务通过服务注册表进行注册，通过服务注册表管理器进行管理，然后在视频流实例使用。
- 服务通过视频流上下文进行获取，得到对应服务的接口，然后通过接口调用服务的能力。视频流实例实现了上下文接口。每个 TAB 都是一个视频流实例，例如关注/推荐/直播等。视频流实例是各种服务的具体承载者。
新架构虽然累计提交了数万行代码，但是核心架构代码只有7个类，合计约800行代码。这800行代码承载了其他数万行业务代码的运转。
重构前的准备
▐ 引入代码规范&静态扫描工具
重构前要确保代码的提交都要符合代码规范，代码静态扫描工具是落地代码规范&保障代码质量的重要手段，可以及时的发掘代码中的问题。
一般的编码问题我们都可以用 Android Studio Lint 扫描出来。
如果你想自定义扫描规则、支持更多语言、甚至搭建自己的静态扫描服务，推荐使用Sonar Lint + Sonar Qube这套方案。相比Android Studio Lint, Sonar Lint扫描出问题以后还会提供解决建议。
▐ 建设工程工具
编写脚本工具，将研发中用到的各种功能精简成一行命令完成，减少人工成本，提升研发效率。
▐ 引入自动化测试
重构的过程中，出错几乎是难以避免的，如果知道出错了就成为一个很重要的问题。自动化测试便成为了侦查错误的重要手段。
- 功能自动化测试：测试同学编写的测试脚本，验证业务的各种功能。
- 稳定性自动化测试：测试同学编写的测试脚本，运行业务的各种功能，以验证程序的稳定性。
- 性能自动化测试：测试同学编写的测试脚本，测试重构后的性能表现。
- 单元测试：开发同学编写的测试用例，从代码角度，验证各个类/函数的功能。单元测试前期成本较高，可酌情按需落地。
