巧妙撰写AngularJS 遗留项目的升级改造之路（一）

目录
序言
遗留项目概述
条件限制下的升级原则
升级改造的演进方向
遇到的主要难点
小结
参考

1. 序言
   Angular 官方网站针对 从 AngularJS 升级到 Angular 提供了比较详细的文档，并给出了一个 PhoneCat 升级教程 的案例演示，指导一步步如何改造。但总的来说，这个案例还是太过简单，并不能很好地还原一个最原始的、相对复杂的、版本更低的遗留项目该如何一步步升级，以及升级过程中可能需要考虑的一些额外因素。

本篇文章会以一个相对复杂的遗留项目为原型来探讨该如何一步步进行渐进式地升级改造，以及针对不同情况可以采取哪些策略，算是一篇结合了实际项目改造后的经验之谈。

2. 遗留项目概述
   遗留项目按照不同业务拆分成了多个业务模块和一个公共模块，即有多个代码仓库，如下图：

代码仓库

从上图可知，遗留项目中主要使用的是 AngularJS 1.4，只有一个模块D使用了高版本的 Angular 。其实如果正确的业务划分，模块D是属于模块C的一个子模块（或一部分）。

原本是考虑将模块C拆分为更多更小的模块，再加上想尝试用较新的 Angular 技术栈来写新功能，在种种原因的促使下最终有了 Angular 高版本的模块D。但是，在后续的开发实践中发现这样的拆分是存在一定问题的（比如维护两套类似逻辑的代码、修改容易疏漏等等），不过由于已经用了高版本的 Angular，无法再简简单单地合并回去。

最终，除了需要考虑如何将 AngularJS 1.4 一步步升级到高版本的Angular ，也需要考虑在升级到一定程度之后将相同业务模块的代码仓库进行合并。