完全重写期间需要完成的工作量是巨大的，因此很难预先估计此类迁移所需的时间和资源。
那些计划迁移但由于时间或资源限制而无法承担完全重写的人可能需要考虑下一种迁移类型。
“快速”迁移：渐进迁移 与完全重写相反，逐步迁移不
电报号码数据 需要等待完全迁移。相反，您可以一点一点地迁移应用程序，并在用户准备好后立即将这些新部分提供给他们。当然，如果我们谈论整个应用程序，称这种类型的迁移“快速”有点夸张，但单独的功能显然可以更快地交付给用户。不过，让我们也给出逐步迁移公正的利弊：
优点：
当向最终用户交付单独的应用程序部分时，逐步迁移确实比完全重写更快，因为我们不需要等待整个应用程序被重写。
通过逐渐交付新的、迁移的位，我们可以随时获得有关它们的反馈（来自最终用户）。与完全重写相比，它使我们能够更快更独立地捕获错误和问题，在完全重写中，我们将迁移的应用程序作为一个整体进行部署，并且可能会忽略一些较小的问题或错误。
为了更好地理解逐步迁移的问题，请尝试在 Vue 到 React 迁移的同一个项目中并行安装 React 和 Vue。我相信你必须真正享受挖掘配置和解决控制台错误才能享受这个过程。然而，我们甚至不需要那么深入。让我们考虑以下遗留示例：
组件，无论 CSS 模块如何，都非常容易受到全局样式的影响。 在这个简单的示例中，我们至少有四种方法可以直观地破坏 Vue 组件。
组件，无论 CSS 模块如何，都非常容易受到全局样式的影响。在这个简单的示例中，我们至少有四种方法可以直观地破坏 Vue 组件。（来源）（大预览）
在这里，我们将 Vue 组件集成到 Vanilla JS 应用程序中，就像潜在的 Vanilla 到 Vue 迁移场景一样。CSS 模块负责 Vue 组件的样式并为您的组件提供适当的范围。然而，正如您所看到的，即使 Vue 组件的样式告诉子标题为绿色，它也是完全关闭的，并且该示例提供了多达四种（但实际上还有更多）破坏组件样式的简单方法。
此外，进入此 Vue 组件的其他全局样式可以完全扩展我们组件的外观，尽管它可能被视为某些项目中的一个功能，但会使事情难以预测和维护，并且不一定是我们想要的。这个例子揭示了渐进迁移中最常见且最难解决的问题： CSS 的“Cascade”部分很容易破坏组件。
这个人为简化的例子还揭示了与逐步迁移相关的其他几个大问题：
因为我们组合了两个不同的系统，所以结果可能会变得非常混乱：我们必须在同一个项目中同时支持两个不同的系统及其依赖项、需求和意见。不同的框架可能需要相同的依赖项，但版本不同，从而导致版本冲突。
由于集成应用程序（在我们的例子中是 Vue）是在主 DOM 树中呈现的，因此 JavaScript 中的全局范围很容易发生冲突：两个系统都可能想要操作不属于它们的 DOM 节点。
此外，让我重复一遍，因为我们将在本文中多次讨论这一点：由于这种集成的全局性质，CSS 在没有太多控制的情况下从一个系统溢出到另一个系统，就像 JavaScript 一样污染全局范围做。
为了解决这些问题（或者至少阻止它们），我们需要实施变通办法、黑客攻击并实施供整个团队遵循的开发风格。这一切都会导致逐步迁移后结果质量降低、受到损害。维护这样的项目也比完全重写后更难。
现有的两种选择都有局限性和约束，但如果需要迁移，我们仍然必须选择一种。然而，这个选择就应该如此痛苦吗？以某种方式结合两者最好的部分，同时最大限度地减少负面影响，不是很好吗？有可能吗？
让我向您介绍弗兰肯斯坦移民。
