iOS 遗留系统重构实践

在过去的几个月内，我主导着团队完成了一项工程浩大（累积八个人月的工作量）的重构工作——为我们的App替换数据库。之所以能够把这种伤筋动骨的事情称之为重构，是因为在这段时间内，我们每天向主干合并两到三次代码，期间App上线五次，用户没有感知到任何影响。在这篇文章中，我将讲述我们如何在不影响系统外部行为，也不影响正常交付的情况下，替换掉了数据库实现。

背景

在一个有着良好分层结构的系统中，每一层都有它自己的职责：显示层负责响应用户事件，调用业务层的逻辑，最后做数据呈现；业务逻辑层负责业务规则与数据处理；数据访问层封装底层数据库的操作，网络访问层与其并列，负责网络请求、json解析等等。无论是MVC、MVVM、VIPER，归根结底都是在”单一职责“、“关注点分离”、“高内聚低耦合”的原则下变化，只是表现形式和涵盖的层次各异。

而在我们的代码中，几乎所有的显示层对象，包括ViewController、ViewModel，甚至View里面都混杂了大量的CoreData API调用，直接进行数据库操作。

粗略统计了一下，系统中一共有25个类与NSManageContext紧紧耦合。形成了下图中混乱的局面：

(点击放大图像)

面对这种情况，我们首先要做的就是解耦。

方案选型

我们最先排除掉的是重写这种简单粗暴的方式。表面上看来，我们可以通过重写得到一个干净利落的方案，层次结构清晰，职责分离；但与之相伴的是巨大的风险：

范围不可控——遗留系统的难点就在于牵一发而动全身，影响范围极广。稍不留神，重写的工作就会如野火燎原般蔓延开来，不可收拾。
长时间无法上线——在整个过程中，直到最后完成的那一刻之前，系统会处于一直不可用的状态。漫长的时间里，所有的新功能都被阻塞，不能交付。没有哪个产品团队能承担这样的结果。

第二个被排除掉的方案是特性分支。把重写的工作放到分支上完成，其他人继续在主干上开发新特性，直到重写结束再合并回主干——这种做法确实比直接重写要好上那么一点点，因为新特性还是可以不受影响的；但长期没有跟主干合并的分支，在经历上四五个月的重写之后，天知道到最后要花多长时间来处理合并冲突？

既想减小对系统的影响，又想不影响新功能上线，又不想处理大量的合并冲突，最后的方案就只剩下了一种，那就是抽象分支（Branch by Abstraction）+特性开关（Feature Toggle）。

抽象分支

抽象分支这个名字的缘起是针对版本库分支而言的，它允许开发者在一条“抽象”的分支上并行工作，无需创建一条实际的分支，从而避免无谓的合并开销。

Martin Fowler和Jez Humble都曾在多年前撰文介绍过这个重构方案

http://martinfowler.com/bliki/BranchByAbstraction.html
http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/

它的工作原理很简单：当我们想要替换掉系统中的某个组件——名为X——时，首先为X组件创造一个抽象层，这一层里面可能会有大大小小若干接口或是协议，把系统中对X组件的访问都隔离在抽象层之下，系统只调用抽象的接口/协议，不会接触到具体的API实现。

这一步我们可以通过提取方法、提取类和接口等重构手法来完成；这以后系统就彻底跟X组件解耦了，它依赖的只是一组抽象接口，而非具体实现。这时候，我们就可以着手在这个抽象层下面，进行新组件的开发工作，让它也实现同一套接口即可。

这之后，我们再使用特性开关（其原理及实现见下节），让这个抽象层在生产环境下调用旧组件，测试环境下调用新组件，从而在完全不影响交付的情况下，完成对新组件的测试。测试结束后，就可以打开开关，让系统在线上使用新组件，等彻底稳定后，把开关代码和旧组件代码全部删掉，替换工作就完成了。

在上述整个开发过程中，任何一个阶段都可以做到细粒度的任务分解，然后小步提交，每次提交都自动触发单元测试和集成测试，保证不影响现有功能。在频繁提交的情况下，也不会出现大量的代码合并冲突，无论是做组件替换还是新特性开发，开发人员都可以基于同一套代码库工作。这就大大减少了对系统的冲击和交付风险。