包阅导读总结
1. 淘宝短视频流、架构再设计、工程重构、架构解耦、快速迭代
2. 本文讲述淘宝短视频流老工程的架构再设计和工程重构，梳理总结了从定义问题、设计架构、准备工作、重构代码到灰度放量的全过程，并介绍了取得的效果。
3.
– 背景：随着业务发展，老工程问题凸显，开启大型重构。
– 准备：深入了解业务及架构，与业务和技术同学对焦。
– 设计新架构：
– 考虑问题：工程大功能多，基于原工程重构，解决整体耦合。
– 定义核心问题：架构解耦&快速迭代。
– 落地方案：纵向分层+横向模块化。
– 重构前准备：
– 引入代码规范&静态扫描工具。
– 建设工程工具。
– 引入自动化测试。
– 重构代码手段：提取、内联、封装、重命名、移动。
– 架构守护：使用 ArchUnit 检查代码架构。
– 灰度放量：做好数据工作，采用 AABB 方式，监控指标，比对验证。
– 效果：新架构在多方面取得较好效果。
思维导图：
文章地址：https://mp.weixin.qq.com/s/65bnM67NzyAyz5vGU18C8g
文章来源：mp.weixin.qq.com
作者：苏策
发布时间：2024/6/16 6:36
语言：中文
总字数：4904字
预计阅读时间：20分钟
评分：83分
标签：
以下为原文内容
本内容来源于用户推荐转载，旨在分享知识与观点，如有侵权请联系删除 联系邮箱 media@ilingban.com
随着视频流业务的发展，业务的复杂性越来越高，视频流老工程在架构设计、代码质量、工程能力等方面的问题也逐渐凸显。本次重构是一次对大型业务工程进行架构再设计和重构的探索，本文是对这次探索的一次梳理与总结。
随着视频流业务的发展，业务的复杂性越来越高，视频流老工程在架构设计、代码质量、工程能力等方面的问题也逐渐凸显。在这样的背景下我们开启了一次对老工程的大型重构。
本次重构是一次对大型业务工程进行架构再设计和重构的探索，本文是对这次探索的一次梳理与总结。
本文是实践篇，讲述如何从 0 到 1 对一个大型的业务工程开展重构。我们将按照定义架构解决的问题、设计架构的实现方式、重构前的准备、开始重构代码、新架构灰度放量的顺序来进行讲述，让我们开启重构之旅吧！
在设计新架构之前，我们需要先充分的了解业务以及业务背后的架构设计和实现，这个过程我们不仅要深入的去看代码，更重要的是和关联的业务同学和技术同学进行不断地对焦，向业务同学了解业务背景，向技术同学了解架构设计意图以及技术开发痛点。
我们可以通过以下方式加深我们的现有业务和工程的理解：
在设计新架构的时候，我们需要考虑以下三个方面的问题。
-
工程大，功能多，可以考虑先基于原工程重构，优先搬移大块的代码，解决整体耦合的问题。最后整体搬移到新工程。
基于上述的问题，我们定义出了新架构要解决的核心问题：”架构解耦&快速迭代“。
在「定义架构解决的问题」章节中，我们定义了新架构要解决的核心问题：”架构解耦&快速迭代“。为此我们的架构需要向组件化架构演进，并且支持动态化发布。
在具体落地方案上我们采用了“纵向分层” +“横向模块化（微服务）”的方式。
纵向分层。代码分为业务层（面向业务需求）、框架层（面向容器功能）和基础层（面向基础代码）。核心解决架构代码和业务代码耦合，框架层无法独立于业务进行迭代，无法跨业务复用等问题。
横向模块化（微服务）。每个模块都是一个服务，一个服务的代码都在一个包下面，对外通过接口提供功能，核心解决不同功能之间的代码相互耦合，内聚性差，日常代码推送冲突率高，功能迭代和下线困难等问题。
新架构虽然累计提交了数万行代码，但是核心架构代码只有7个类，合计约800行代码。这800行代码承载了其他数万行业务代码的运转。
1）引入代码规范&静态扫描工具：重构前要确保代码的提交都要符合代码规范，代码静态扫描工具是落地代码规范&保障代码质量的重要手段，可以及时的发掘代码中的问题。
一般的编码问题我们都可以用 Android Studio Lint 扫描出来。
如果你想自定义扫描规则、支持更多语言、甚至搭建自己的静态扫描服务，推荐使用 Sonar Lint + Sonar Qube 这套方案。相比 Android Studio Lint ，Sonar Lint 扫描出问题以后还会提供解决建议。
2）建设工程工具：编写脚本工具，将研发中用到的各种功能精简成一行命令完成，减少人工成本，提升研发效率。
3）引入自动化测试：重构的过程中，出错几乎是难以避免的，如果知道出错了就成为一个很重要的问题。自动化测试便成为了侦查错误的重要手段。
-
功能自动化测试：测试同学编写的测试脚本，验证业务的各种功能。
-
稳定性自动化测试：测试同学编写的测试脚本，运行业务的各种功能，以验证程序的稳定性。
-
性能自动化测试：测试同学编写的测试脚本，测试重构后的性能表现。
-
单元测试：开发同学编写的测试用例，从代码角度，验证各个类/函数的功能。单元测试前期成本较高，可酌情按需落地。
重构代码的常见手段，IDE（IDEA/Android Studio）都为我们提供了支持，”非不要不要手动移动代码，减少出错的可能性“。
-
提取（Extract）：重构的重用手段，大化小，繁化简，提升代码的可读性。
-
内联（Inline）：独立的函数、变量没有对提升代码可读性有帮助，可以进行消除，内联到对应的调用位置上。
-
封装（Encapsulate）：封装是实现高内聚的有效手段，“对不变的部分进行封装，为变化的部分提供扩展”。
-
重命名（Rename）：函数/变量的重命名有助于提升代码的可读性，如果一个函数/变量无法用一个合适的单词表达，说明这个函数/变量违反了“单一职责”，需要重新进行设计。
-
移动（Move）：移动函数/变量，把负责同一个职责的函数/变量放在一起，提升代码的内聚。
一套新架构设计并落地后，我们还需要有效的手段守护架构不被后续的修改破坏。这个手段需要落到具体的工具上，单纯的文档规范无法做到这一点。这个时候架构守护ArchUnit就派上用场了。
ArchUnit是一个免费、简单且可扩展的库，它可以用 Java 单元测试框架来检查 Java 代码的架构，包括检查包和类、层和片之间的依赖关系，可以作为“架构的守护门禁”。如下所示：
ArchUnit可以从以下几个方面对代码进行约束。
在灰度放量之前，要先做好数据工作，包括数据埋点以及数据可视化，监控的指标包括：
-
新架构生效率（分钟表/天表）
-
新架构版本大盘（分钟表/天表）
-
新架构错误码大盘（分钟表/天表）
-
新架构性能大盘（分钟表/天表）
-
稳定性：Java Crash 、ANR 等
-
性能：首帧、帧率、内存等
放量的时候，可以采用AABB的方式，两个实验桶，两个对照桶，相互比对验证，记录每天的性能数据、业务数据的变化，及时修复问题。
新架构重构累计 Commit400余次，代码变动行数数万行。新架构落地以后，在架构设计、代码质量、工程能力等方面取得了比较好的效果。
好了，本次的工程重构的分享到这里就结束了，不知道读者在平时的工作中有没有遇到重构工程的情况呢，有什么心得体会，欢迎评论区留言交流~
[12]Android Studio Lint
https://developer.android.com/studio/write/lint?hl=zh-cn
[13]Sonar Lint
https://www.sonarsource.com/products/sonarlint/
[14]Sonar Qube
https://www-sonarsource-com.translate.goog/products/sonarqube/?_x_tr_sl=en&_x_tr_tl=zh-CN&_x_tr_hl=zh-CN&_x_tr_pto=sc
