随着视频流业务的发展，业务的复杂性越来越高，视频流老工程在架构设计、代码质量、工程能力等方面的问题也逐渐凸显。在这样的背景下我们开启了一次对老工程的大型重构。
本次重构是一次对大型业务工程进行架构再设计和重构的探索，本文是对这次探索的一次梳理与总结。限于篇幅，文章总共分为理论篇和实践篇两个部分。
思维导图如下所示：
本文是理论篇，主要讲述持续重构的重要性、如何设计好架构以及如何写出好代码，为实践篇做一个理论上的铺垫。
在日常的工作中，我们经常会面临接手一个年久失修“老工程”的情况，这样的工程往往经历过多个人甚至多个团队的维护。大部分人通常会带着短期目的（需求迭代、体验优化）去修改工程代码。
由于没有了解工程的整体架构，整个工程就会随着修改逐渐腐坏变质。最终代码变得越来越难维护，新功能也越来越难扩展，一个小小的改动也可能引起难以预想的 Bug。
“一个人，一杯水，一个 Bug 修一天”
如果不去改善工程架构，最终这个工程会变得难以维护，超过一定阈值后，新的大型功能无法引入，或者大的性能优化无法展开，整个工程只能被迫重写。而改善工程架构的有效手段就是“**持续重构**”。
软件设计大师马丁•福勒（Martin Fowler）在他的著作《重构：改善代码既有的设计》是这样定义重构：
重构（refactoring）对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
在这个定义中指出了重构的两个关键要素：
重构的价值主要体现在它的软件架构、工程质量、和研发效率的促进作用。
如果一个工程在开发、测试和发布阶段有以下特征，那么这个工程需要进行重构了。
诚然重构会有诸多好处，但是它也会带来很多挑战，我们需要在重构之前需要充分的评估这些挑战。
1）重构的效率问题
2）重构的安全性问题
3）重构的落地问题
面对重构的诸多挑战，我们需要更加科学有效的手段来解决这些问题，具体说来：
架构设计的一点体会
“**架构的坏味道**”主要体现在代码设计层面的问题，这些问题会导致整个软件系统难以理解和维护，无法很好的承接当前&以后的业务需求。
我们可以借助一些工具来提升分析架构的效率：
我们平时开发中听的比较多的是“**设计模式**”，所谓“**设计模式**”，其实就是写代码的优秀套路。架构设计也有套路可循，被称为“**架构模式**”或者“架构风格**”**，常见的架构风格如下所示：
以上架构风格都是前人对于架构设计的总结。对于客户端的角度，我们有自己的独特的架构风格，这些架构都是上面一种或者两种演化得来，让其更符合客户端的实际情况。
单体化架构是常见的架构模式之一。所有业务功能都在一个模块里，开发人员都在一起开发。单体架构非常适合团队规模小、业务复杂度低的产品，在项目起始阶段能快速迭代进行验证。
优点：
缺点：
鉴于单体化架构的问题，我们需要去掉每个业务功能之间耦合关系，让每个模块彼此独立，这样业务模块就变成了业务组件，整个架构就朝着组件化架构发展。
组件化架构采用多个模块开发，将代码按照业务功能和基础功能进行划分，拆分成多个独立的组件。开发人员可以基于不同的模块进行独立开发和编译调试，最后发布时再集成所有组件。测试人员可以提前对组件进行功能验收，更快推进测试，避免将所有的测试工作都堆积在最后的集成阶段。
组件化后，复杂度会转移到基础设施之上。这时候我们需要引入路由框架、依赖注入框架、组件通信框架等解决组件通信、组件依赖等问题。并且还需要引入自动化流水线（集成打包平台）来降低组件集成时的复杂度。
优点：
缺点：
上述的组件化架构是针对一个 APP 来说的，我们日常开发更多的时候是面对一个或者几个业务模块，这个时候我们可以借鉴组件化框架“高内聚低耦合”的精髓，实现一套变种的组件化架构。代码可以在一个模块里，用包来划分功能，每个包里面的代码实现“高内聚低耦合”。
组件化架构已经完美解决业务功能耦合问题，实现了业务功能、基础功能的复用。但是业务的每次功能上新都依赖 APP 发版，迭代周期较长，业务团队希望能够动态发布业务需求。在这种诉求下，就需要往插件化架构演进了。
插件化架构通常是基于组件化架构演化来的，目的就是支持组件的动态加载和升级。这种架构适用于业务复杂度高且需要独立迭代、快速触达用户的产品。
它一方面可以有效减少应用的体积，另一方面可以让业务插件进行独立的规划演进。
优点：
缺点：
插件化架构的发展核心动力还是源于业务快速增长时期，业务对于迭代效率以及包大小的诉求，早期的插件化技术都是通过 hook 系统 API 的方式进行的插件加载，例如Altas、irtualApp、Shadow、RePlugin等，直到后来 Google 推出了官方的动态化方案Android App Bundle。
插件化架构有效的提升了迭代效率，但是随着市场竞争的加剧，业务团队希望能够支持更多的平台，实现一码多端，一来进一步提升研发效率，而来减小不同平台之间的功能差异。这个时候架构就朝着容器化架构演进。
移动互联时代下，很多产品都需要支持多个平台，如 Android、iOS、鸿蒙等。为了减少跨平台的开发和维护成本，容器化跨平台技术成了目前主流的架构形式之一。
跨平台技术始终在效率和性能两个指标间寻找平衡，从WebView渲染、原生渲染（React Native、Weex）再到自建渲染（Flutter），也发展出了很多方案。
优点：
缺点：
“**代码的坏味道**”是代码中设计不合理的地方，它们虽然不是Bug，但是会影响代码的可读性、可扩展性以及可维护性。以及在将来埋下线上隐患。
“**当你在看一个巨长的类时**”
神秘命名**：**不够直观/难以理解的类名、函数名与字段名。一个不够清晰的命名不仅阻碍了其他人去理解代码，也侧面反应了代码存在设计上的问题，例如职责不单一等，进而导致无法找到一个合适的名字。
重复代码**：多段重复/相似的代码。这类代码往往都是“拷贝式编程”**带来的问题，担心引入新问题或者懒得写新的，直接拷贝一份代码实现自己的逻辑。重复/相似的代码需要提炼成函数。
无用代码**：**存在未被调用的类、方法。增加了认知负担和维护成本。
全局类/全局数据/静态类**：**全局/静态类是一种反模式的实现，它破坏了封装性，在代码的任何地方都可以调用/修改它。除此之外，还会导致内存泄露等问题。
可变数据/集合**：**数据/集合的随处修改会引发难以预料的问题，破坏了封装性，对于变量尽量定义成final的，非必要不暴露set方法。对于集合，如何需要可以进行保护性拷贝。
滥用的继承**：继承本身是用来复用代码，但是当一个继承变得庞大，继承链变得很长，那这套继承就变得难以维护。继承的使用提升父类的封装性，控制继承链的长度。非必要不使用继承，可以用“对象组合替代继承”**。
过长的函数**：**动辄铺满一个屏幕的函数。什么样的函数算长，IDE一个屏幕都看不完的函数就算长，上下滑动IDE会打乱看代码人的思维。函数越长，越难以理解，大函数需要按照功能拆解成小函数。
过长的参数列表**：“一个函数，N个参数，神秘的Boolean入参，函数传参像是在排列组合**”。过长的参数列表，会大大的增加使用者的理解成本和出错机会。参数过多的时候，可以把这个参数定义一个类，把类作为入参。
过大的类**：**动辄几千行的超大类，每次功能迭代，都会改到这个类，无穷无尽的代码冲突和线上Bug。过大类也是代码质量的万恶之源。过大类可以按照功能拆分成更小的类。
过少/过多的注释**：“程序员最讨厌的两件事情，自己去写注释，别人不写注释**”。没有注释当然是不好的，别人读你的代码会像读天书一样。满屏的注释也是不好的，写代码不是写作文，精简你的注释，保留必要的代码说明，“**良好的函数命名，让代码会说话**”。
一般的编码问题我们都可以用Android Studio Lint扫描出来。
如果你想自定义扫描规则、支持更多语言、甚至搭建自己的静态扫描服务，推荐使用Sonar Lint+Sonar Qube这套方案。相比Android Studio Lint，Sonar Lint扫描出问题以后还会提供解决建议。
上文提到可以借助Lint工具扫描出大部分的不优雅代码实现。而对于代码设计上的问题，我们则需要借助设计原则、设计模式这些手段来加以解决。关于这部分的内容网上有很多资料，就不再展开了。这里列举了常用的设计原则和设计模式。
设计原则：
设计模式：
理论篇的内容就讲到这里了，下一篇《淘宝短视频流工程重构（下）：实践篇》将讲述如何从 0 到 1 对一个大型的业务工程开展重构。我们将按照定义架构解决的问题**、设计架构的实现方式、**重构前的准备、开始重构代码、新架构灰度放量的顺序来进行讲述，将于6月14日进行推送，让我们开启重构之旅吧!
本文由微信公众号大淘宝技术原创，哈喽比特收录。
文章来源：https://mp.weixin.qq.com/s/V5ga60hfqlvYE-lYD7kz9Q
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而，京东官方通过微博发言人发布的消息澄清了这些传言，称这些言论纯属虚假信息和蓄意捏造。
日前，据博主“@超能数码君老周”爆料，国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。
据报道，荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦（ASML）CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。
今年早些时候，抖音悄然上线了一款名为“青桃”的 App，Slogan 为“看见你的热爱”，根据应用介绍可知，“青桃”是一个属于年轻人的兴趣知识视频平台，由抖音官方出品的中长视频关联版本，整体风格有些类似B站。
日前，威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”，同时，他发文表示：中国汽车普及率低于非洲国家尼日利亚，每百户家庭仅17户有车。意大利世界排名第一，每十户中九户有车。
近日，一项新的研究发现，维生素 C 和 E 等抗氧化剂会激活一种机制，刺激癌症肿瘤中新血管的生长，帮助它们生长和扩散。
据媒体援引消息人士报道，苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后，3D系统一度大涨超10%，不过截至周三收盘，该股涨幅回落至2%以内。
9月2日，坐拥千万粉丝的网红主播“秀才”账号被封禁，在社交媒体平台上引发热议。平台相关负责人表示，“秀才”账号违反平台相关规定，已封禁。据知情人士透露，秀才近期被举报存在违法行为，这可能是他被封禁的部分原因。据悉，“秀才”年龄39岁，是安徽省亳州市蒙城县人，抖音网红，粉丝数量超1200万。他曾被称为“中老年...
9月3日消息，亚马逊的一些股东，包括持有该公司股票的一家养老基金，日前对亚马逊、其创始人贝索斯和其董事会提起诉讼，指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。
据消息，为推广自家应用，苹果现推出了一个名为“Apps by Apple”的网站，展示了苹果为旗下产品（如 iPhone、iPad、Apple Watch、Mac 和 Apple TV）开发的各种应用程序。
特斯拉本周在美国大幅下调Model S和X售价，引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金（Future Fund）管理合伙人加里·布莱克发帖称，降价是一种“短期麻醉剂”，会让潜在客户等待进一步降价。
据外媒9月2日报道，荷兰半导体设备制造商阿斯麦称，尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效，但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。
近日，根据美国证券交易委员会的文件显示，苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元（约 4.65 亿元人民币）。用于在 2023-2025 年期间，发射卫星，进一步扩展苹果 iPhone 系列的 SOS 卫星服务。
据报道，马斯克旗下社交平台𝕏（推特）日前调整了隐私政策，允许 𝕏 使用用户发布的信息来训练其人工智能（AI）模型。新的隐私政策将于 9 月 29 日生效。新政策规定，𝕏可能会使用所收集到的平台信息和公开可用的信息，来帮助训练 𝕏 的机器学习或人工智能模型。
9月2日，荣耀CEO赵明在采访中谈及华为手机回归时表示，替老同事们高兴，觉得手机行业，由于华为的回归，让竞争充满了更多的可能性和更多的魅力，对行业来说也是件好事。
《自然》30日发表的一篇论文报道了一个名为Swift的人工智能（AI）系统，该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。
近日，非营利组织纽约真菌学会（NYMS）发出警告，表示亚马逊为代表的电商平台上，充斥着各种AI生成的蘑菇觅食科普书籍，其中存在诸多错误。
社交媒体平台𝕏（原推特）新隐私政策提到：“在您同意的情况下，我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”
2023年德国柏林消费电子展上，各大企业都带来了最新的理念和产品，而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。
罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品，具体内容为：“以我对我‘子公司’的了解，我认为 iPhone 15 跟 iPhone 14 不会有什么区别的，除了序（列）号变了，这个‘不要脸’的东西，这个‘臭厨子’。
