开始重构代码
小步安全的重构
- 小步：将整个重构分解为小的步骤，例如一次方法提取，一次方法移动。每一次小的重构后可以通过版本管理工具进行保存，这样方便我们及时将代码进行回滚。
- 频繁运行测试：每当有一次小的重构完成后都需要频繁执行测试，如果这个时候测试有异常，就证明我们的重构破坏了原有的功能，需要进行排查。通过这样的反馈，我们可以在更早期发现问题并及时处理。
- 使用 IDE 的安全重构功能：使用自动化重构可以有效减少人为修改代码带来的风险，并且效率也会更高。
▐ 如何安全地重构
重构代码的常见手段，IDE（IDEA/Android Studio）都为我们提供了支持，”非不要不要手动移动代码，减少出错的可能性“。
- 提取（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）：继承虽然可以实现代码复用，但是也带来了两个问题：
|
|
▐ 如何持续守护新架构
一套新架构设计并落地后，我们还需要有效的手段守护架构不被后续的修改破坏。这个手段需要落到具体的工具上，单纯的文档规范无法做到这一点。这个时候架构守护ArchUnit就派上用场了。
ArchUnit是一个免费、简单且可扩展的库，它可以用Java单元测试框架来检查Java代码的架构，包括检查包和类、层和片之间的依赖关系，可以作为“架构的守护门禁”。如下所示：
ArchUnit可以从以下几个方面对代码进行约束：
约束 |
示意图 |
约束包之间的依赖关系 |
|
约束类之间的依赖关系 |
|
约束包和类的包含关系 |
|
约束类之间的继承关系 |
|
约束类的注解 |
|
约束层之间的依赖关系 |
|
约束循环依赖 |
新架构灰度放量
在灰度放量之前，要先做好数据工作，包括数据埋点以及数据可视化，监控的指标包括：
- 新架构数据大盘
- 新架构生效率（分钟表/天表）
- 新架构版本大盘（分钟表/天表）
- 新架构错误码大盘（分钟表/天表）
- 新架构性能大盘（分钟表/天表）
- ...
- 稳定性：Java Crash 、ANR 等
- 性能：首帧、帧率、内存等
- 舆情
在灰度放量开始之后，又分为两个小阶段：
- 放量到 10% 之前：这个阶段主要观察稳定性数据，有没有 Java Crash，ANR 等。
- 放量到 10% 之后：这个阶段主要观察性能数据、业务数据，有没有线上舆情等，
放量的时候，可以采用AABB的方式，两个实验桶，两个对照桶，相互比对验证，记录每天的性能数据、业务数据的变化，及时修复问题。
新架构落地效果
新架构重构累计Commit 400余次，代码变动行数数万行。新架构落地以后，在架构设计、代码质量、工程能力等方面取得了比较好的效果。
▐ 架构设计
▐ 代码质量
▐ 工程能力
本次的工程重构的分享到这里就结束了，不知道读者在平时的工作中有没有遇到重构工程的情况呢，有什么心得体会，欢迎评论区留言交流~
参考资料
- Android Studio Lint
https://developer.android.com/studio/write/lint?hl=zh-cn
- Sonar Lint
https://www.sonarsource.com/products/sonarlint/
- Sonar Qube
团队介绍
我们是淘天集团-内容技术团队，是承担淘宝内容化战略的核心技术力量。负责面向消费者的淘宝直播、淘宝逛逛等核心业务场域；面向千万级商家、品牌、机构、达人提供内容创作工具、内容运营平台、内容商业化解决方案；以及面向阿里巴巴电商板块各业务线提供内容管理、内容总线等基石平台。
