增量迁移

2008年7月7日

与任何行业一样，软件开发中也有一些经常被遗忘的活动，这些活动通常被忽略，但却总是在最糟糕的时刻给你带来麻烦。数据迁移就是其中之一。

大多数新的软件项目都涉及到存储在其他地方的数据，这些数据需要在新系统上线后迁移到新系统中。系统替换可能需要迁移所有旧数据，新功能可能需要从其他系统加载数据。

人们通常不会认真对待这项任务。毕竟，它只是读取一些数据，稍微处理一下，然后加载到新系统中。此外，代码只需要运行一次，因此没有必要使其特别快或美观。一旦迁移完成，代码就可以安全地丢弃。

当然，在项目结束之前，没有必要担心它，因为你只想在新系统上线之前运行迁移。

我对我的读者评价很高，如果只是因为他们对软件写作的品味，所以我相信我能看到他们若有所思的微笑。数据迁移通常在白板抽象的安全性下看起来很容易，但通常充满了令人讨厌的细节，会让你措手不及。

你可能会怀疑现有数据有些混乱，但每个人通常都会对数据的实际混乱程度感到惊讶。因此，整个过程通常比它应该的要复杂得多。
因为它是单次使用的、一次性代码，所以人们不会在迁移代码的设计上投入太多精力，因为他们认为它低于设计回报线。这种假设通常是错误的，特别是考虑到上一点。
做一件膨胀成比你想象的更难的事情从来都不是一件有趣的事，但当你把它留到接近发布日期的时候，你就是在给麻烦一个大大的签约奖金。

在敏捷环境中，我喜欢用这样一句妙语：*如果它让你痛苦，就更频繁地去做*。它表面上的不合逻辑使它令人难忘，而且其中蕴含着一个真正的道理。许多困难的活动可以通过更频繁地进行而变得更加简单。XP实践者尤其以将这一原则应用于测试、集成、设计和计划而闻名——因此，将其应用于数据迁移也就不足为奇了。

我第一次看到这样做是在一个中等规模的项目（十几个开发人员，为期一年）中，由我的同事Josh Mackenzie完成的，该项目在最近的过去曾两次尝试失败。他决定每两周迭代一次数据迁移。每次迭代，团队都会找出他们需要添加哪些数据来支持正在构建的新功能，并更新数据迁移系统，以便从实时系统中迁移这些额外的数据。

与这类事情一样，它最终的结果远没有人们担心的那么不可能，而由此带来的风险和压力的降低使其成为一个值得的选择。他们赞赏显而易见的好处，这些好处可以归结为在接近上线时明显缺乏仓促的恐慌。

然而，最有趣的好处是他们没有预料到的。增量迁移大大改善了与领域专家的沟通。通常，当你想要与领域专家讨论用例时，你会编造一些假想的场景。通过使用增量数据迁移，团队养成了使用真实示例的习惯，这对于领域专家来说更容易理解。此外，当开发人员提供构建版本供领域专家查看时，它还包括了实时数据的副本。因此，领域专家可以调查新系统如何处理他们最近遇到的棘手案例。特别棘手的问题可以很容易地复制到测试环境中。