AngularJS 1.4全面升级到Angular8.我应该迁移到1.5然后升级还是重写? [英] AngularJS 1.4 full scale upgrade to Angular 8. Should I migrate to 1.5 then upgrade or just rewrite?

问题描述

我已经做了大量研究，但是没有发现任何可以帮助我确定最佳路线的东西(垂直切片，水平切片或只是完整的重写).我正在开发一个非常大型的程序，该程序非常丑陋，没有任何注释，如果可能的话，需要将其迁移到Angular 8，或者至少迁移到Angular7.很多人似乎推荐解决方案

乍一看似乎不太像，但是重写通常比升级更经济高效.似乎升级是重新部署最快的时间，但是根据我的经验，如果您将两者并排进行，则可能会发现时间相似，只是迁移部署必须全部或全部不进行.重新编写意味着您可以使用减少的功能进行部署并构建功能.

更重要的是，对升级站点的持续维护变得越来越困难/耗时.您实际上是在以前的补丁程序和修补程序之上应用了创可贴.

有一些新概念，对我们过去使用第三方或自成一体的指令和控件的更好的本机支持，这是一种全新的理解语言.借此机会清除解决方案的技术债务.

重写-混合

您是否需要一次性部署传送?您对品牌重塑感兴趣吗?
微软过去做得很好的一件事是 Preview 门户的混合推出.

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

几年前，我们有一个功能齐全的门户网站界面，用于管理Azure资产.当他们开始使用全新的用户体验时，这后来被称为经典门户. 在第一版中，菜单系统已基本完成，我们可以在新门户中导航大多数资产，但是当您使用尚未经过重新设计的功能时，该链接会将您带回到经典门户. >

因此，您可以执行相同的操作，将两个用户界面部署到不同的URL，首先要确保身份验证和导航已基本完成，但要使所有链接都将用户带回到原始界面.然后逐个功能地实现新界面，但是由于您无法控制所有内容，因此请在每个页面上保留一个按钮或链接，以使用户返回到原始实现，直到回归测试确认您已达到功能均等为止.

这是MS Hybrid方法的另一个关键优势，如 Will 之类的重大变化会惹恼您的用户.因此，在过渡期间，允许用户选择自己迁移的时间.最初，MS在登录时实现了此目的，用户可以在两个主要URL上登录，然后根据您的个人资料将您重定向到您选择的门户.

最后一步是通过使旧门户中的导航和链接直接导航到新界面来限制对旧界面中功能的访问. -或以减少干扰为目的，在您强迫在旧站点中进行重写的每个页面中添加寿命终止"横幅.

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

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

• 首先迁移到AngularJS 1.5
  此操作仅比升级到Angular2 +稍微容易一些.下面的所有参数在进行下一次升级时都同样适用于此过程. 首先转到1.5的原因之一是摆脱了没有简单直接升级到2+的旧式依赖项.

  • 在升级到1.5之前，您应该考虑实现基于组件的体系结构(如果当前代码为尚未这样做)
    组件的关键要素是更少的配置和简化的设计，因此，请阅读以下内容:无需升级，可以减少出错的地方

    当然，组件与当前的Angular实现更加紧密地结合在一起，如果您还没有使用AngularJS组件，那么这可能是学习Angular 2+之前了解的一个很好的迭代步骤.

• 没有评论
  这是比您想象的更大的红旗.如果未记录代码库，则每次维护都将变得越来越困难，因为每次必须重新阅读和重新解释代码，才可以影响更改.
  因此，如果要进行迁移，则需要重新阅读和理解在某点谈论每行代码的地方，以确保它在

中正常工作.

• AngularJS 1+ => Angular2 +
  虽然可以迁移某些核心框架和第三方库，但大多数控制器 javascript 文件不能简单地迁移到 typescript ，而无需付出很多努力.在 javascript 中，在类型定义和定义位置方面经常碰壁是很普遍的，这意味着在迁移之后，您将花费大量时间一次浏览大多数javascript文件.

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

I have done a ton of research and haven't found anything that has helped me decide what will be the best route (vertical slicing, horizontal slicing, or just a complete rewrite). I am working on a very LARGE program that is very ugly with no comments and need to migrate it over to Angular 8 if possible or at least up to Angular 7. A lot seem to recommend https://angular.io/guide/upgrade however, they don't help too much in migrating to 1.5 first. Does anybody have experience with a large scale migration? Currently, the program is not being used so downtime is no issue.

解决方案

It doesn't seem like it at first, but a re-write is usually a more cost effective solution than an upgrade. It seems like upgrade would be the fastest time to re-deployment but in my experience if you did the two side-by-side you might find the times similar, except that the migration deployment will have to be all or nothing, where as a re-write means you can deploy with reduced functionality and build up the feature.

More importantly, the on-going maintenance of an upgraded site becomes exponentially harder/time consuming. You're really applying band-aides over the top of previous patches and fixes.

There are new concepts, better native support for directives and controls that we used to use 3rd parties for or roll own own, and it's an entirely new language to understand. Take this opportunity to wipe the slate clean of your solution's technical debt.

Rewrite - Hybrid

Do you need to deploy eveything in one go? Are you interested in Re-Branding?
One thing the Microsoft have done well in the past is the hybrid roll-out of their Preview portals.

The best case study IMO is the Azure Portal.

A few years ago we had a pretty fully featured portal interface for managing Azure assets. This would later become known as the Classic Portal when they started work on an entirely new user experience. At first release the menu system was largely complete, we could navigate most assets in the new portal but when you came to features that had not been redesigned yet the link took you back to the Classic Portal.

So you could do the same, have the two user interfaces deployed to different URLs, start by making sure the authentication and navigation is largely complete but make all links take the user back to the original interface. Then feature by feature, implement the new interface, but because you can't control everything, keep a button or link on each page that takes the user back to the original implementation until your regression testing confirms that you have reached feature parity.

That is another key take-away from the MS Hybrid approach, significant change like this WILL annoy your users. So while you are in transition, allow the user to choose when they themselves migrate over. Initially MS achieved this at login, the user could login at either of the main urls, and based on your profile you would be redirected to the portal of your choice.

The last step is to restrict access to features in the old interface, by making the navigation and links in the old portal navigate directly into the new interface. - or less intrusive, add an 'end of life' banner in each page that you have compelted the re-write on in the old site.

Do not confuse this with the Preview Mode in Office 365, the Azure Preview Portal was a ground-up re-write and is still in progress. There are many licensing operations that I still use the Classic Portal for as I still manage some Classic Only azure assets that have not yet been re-deployed.

I would consider the following issues when choosing between Migration/Upgrade and a straight up re-write:

• Migrate to AngularJS 1.5 first
  This operation is only marginally easier than the upgrade to Angular2+. All of the arguments below apply equally to this process as they do the next upgrade. One of the reasons to goto 1.5 first is to escape the legacy dependencies that do not have a simple direct upgrade to 2+.

  • During the upgrade to 1.5 you should consider implementing Component based architecture (if the current code does not already do so)
    A key element of components is less configuration and simplifed design, so read this as less to upgrade, less that can go wrong

    Components are of course more closely aligned with current Angular implementations, if you do not yet use AngularJS Components, that might be a good iterim step to understand before learning Angular 2+

• No Comments
  This is a bigger red flag than you think. If the code base is not documented then any sort of maintenance becomes incrementally harder as each time the code must be re-read and re-interpreted before you can affect change.
  So if a migration is on the cards, where talking about every line of code at some point needed to be re-read and understood to make sure that it works correctly in the

• AngularJS 1+ => Angular2+
  While some of the core frameworks and 3rd party libraries can be migrated, most controller javascript files cannot be simply migrated to typescript without a fair amount of effort. It's pretty common in javascript to cut a lot of corners in terms of type definitions and locations of definitions that mean after migration you will spend a lot of time going back through most javascript files one method at a time.

• Very large
  This is a strong candidate for automation or migration but ultimately it means that the total surface area to test, debug and re-design is also very-large. If the initial migration does not compile, it could be a long road of tweaking before you can get the user interface up so you can start interface testing.

这篇关于AngularJS 1.4全面升级到Angular8.我应该迁移到1.5然后升级还是重写?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！