AngularJS 1.4 全面升级到 Angular 8。我应该迁移到 1.5 然后升级还是重写？ [复制]

Question

我进行了大量研究，但没有发现任何可以帮助我确定最佳路线的方法（垂直切片、水平切片或完全重写）。我正在开发一个非常大的程序，该程序非常难看，没有 cmets，如果可能，需要将其迁移到 Angular 8 或至少迁移到 Angular 7。似乎很多人推荐 https://angular.io/guide/upgrade 但是，它们也无济于事首先迁移到 1.5。有人有大规模迁移的经验吗？目前，该程序没有被使用，所以停机时间没有问题。

Answer 1

起初看起来并不像，但重写通常是比升级更具成本效益的解决方案。升级似乎是重新部署的最快时间，但根据我的经验，如果您同时进行这两个操作，您可能会发现时间相似，除了迁移部署必须全部或全部，其中作为重写意味着您可以使用减少的功能进行部署并构建功能。

更重要的是，升级站点的持续维护变得更加困难/耗时。您实际上是在以前的补丁和修复之上应用创可贴。

对于我们过去使用 3rd 方或自行开发的指令和控件，有新概念、更好的原生支持，而且它是一种全新的语言，易于理解。借此机会清除解决方案的技术债务。

重写 - 混合

您需要一次性部署所有内容吗？您对品牌重塑感兴趣吗？
微软过去做得很好的一件事是他们的Preview门户的混合推出。

最好的 IMO 案例研究是 Azure 门户。

几年前，我们有一个功能非常齐全的门户界面来管理 Azure 资产。后来，当他们开始致力于全新的用户体验时，这将被称为经典门户。 在第一个版本中，菜单系统基本完整，我们可以在新门户中浏览大部分资产，但当您遇到尚未重新设计的功能时，链接会将您带回经典门户。 p>

所以您也可以这样做，将两个用户界面部署到不同的 URL，首先确保身份验证和导航基本完成，但让所有链接将用户带回原始界面。然后逐个功能，实现新界面，但由于您无法控制所有内容，请在每个页面上保留一个按钮或链接，将用户带回原始实现，直到您的回归测试确认您已达到功能奇偶性。

这是 MS Hybrid 方法的另一个关键点，像这样的重大变化会惹恼您的用户。因此，当您处于过渡阶段时，允许用户选择他们自己何时迁移。最初，MS 在登录时实现了这一点，用户可以在任一主 url 登录，并且根据您的个人资料，您将被重定向到您选择的门户。

最后一步是通过使旧门户中的导航和链接直接导航到新界面来限制对旧界面中功能的访问。 - 或者不那么侵入性，在您在旧网站上强制重写的每个页面中添加一个“生命终结”横幅。

不要将此与 Office 365 中的预览模式混淆，Azure 预览门户是一个全新的重写，并且仍在进行中。我仍然使用 Classic Portal 进行许多许可操作，因为我仍然管理一些尚未重新部署的 Classic Only azure 资产。

在迁移/升级和直接重写之间进行选择时，我会考虑以下问题：

• 首先迁移到 AngularJS 1.5
  此操作仅比升级到 Angular2+ 稍微容易一些。下面的所有论点都同样适用于这个过程，就像它们进行下一次升级一样。 首先转到 1.5 的原因之一是为了避开没有简单直接升级到 2+ 的遗留依赖项。

  • 在升级到 1.5 期间，您应该考虑实施 Component based architecture（如果当前代码尚未这样做）
    组件的一个关键元素是更少的配置和简化的设计，所以将其理解为升级更少，出错更少

    组件当然更接近于当前的 Angular 实现，如果您还没有使用 AngularJS 组件，这可能是在学习 Angular 2+ 之前了解的一个很好的临时步骤

• 无评论
  这是一个比你想象的更大的危险信号。如果没有记录代码库，那么任何形式的维护都会变得越来越困难，因为每次都必须重新阅读和重新解释代码才能影响更改。
  因此，如果要进行迁移，那么在某些时候谈论每一行代码都需要重新阅读和理解，以确保它在

• AngularJS 1+ => Angular2+
  虽然可以迁移一些核心框架和第 3 方库，但大多数控制器 javascript 文件不能简单地迁移到 typescript 而不需要相当大的努力。在 javascript 中，在类型定义和定义位置方面偷工减料是很常见的，这意味着在迁移之后，您将花费大量时间一次一次地通过一种方法返回大多数 javascript 文件。

• 非常大
  这是自动化或迁移的有力候选者，但最终意味着测试、调试和重新设计的总表面积也非常大。如果初始迁移未编译通过，则可能需要进行很长的调整才能启动用户界面以便开始界面测试。