一、更新
依赖和框架版本升级
当修订号发生变更时，通常只是进行一些Bug的修复，不需要我们做出响应
当次版本号发生变更时，往往可能会发生一些API变更，我们要视向下兼容情况来决定是否跟进
当主版本号变化时，可能有些API已经不存在了，我们需要大量地改动应用
语言版本升级
遗留系统重搭
二、迁移方式
微前端
寻找合适的微前端技术
确认可行的微前端方案
尝试使用其中的某些方案
对比、讨论几种不同方案的利弊
决定适合当前项目实施的方案
尝试在一个项目中使用新架构开发
编写架构决策记录及文档，记录实施过程中常见的问题
对项目成员进行相关培训
寻找容器
iframe
Electron
Cordova
Ionic
React Native
Flutter
三、重构
架构重构
创建新的重构分支
从简单的重构开始练习，如目录调整、重命名变量
小步提交，使用细致化的版本管理，方便出错后回退管理
对复杂的代码进行样式拆分、逻辑拆分、组件拆分，对于函数来说，可以采取提取变量的方式进行
修改或者编写测试，保障业务功能正常
对于复杂的功能，寻找合适的人一起完成重构
组件提取、函数提取、样式提取
引入新技术
新的编程理念
引入新的框架特性
解决语言糟粕
四、重写
重写前需要考虑的因素
重构、迁移、升级真的不能解决问题吗？
重写的时间预期是多少？
能接受重写的成本吗？
是否整理出完整的功能列表？
产品是否领先于市场？
是否有能力同步维护两个产品和团队？
在重写完成之前，是否可能变为遗留系统？
梳理业务
沉淀新架构
选择更合适的技术栈
进行组件和系统的防腐设计
系统与应用间的解耦设计
五、重新架构
重搭架构
重新设计构建系统，以支撑新架构
设计模块化的应用架构，以帮助我们解耦模块
抽象化组件、提取函数库，以减少重复代码
采用微前端技术来解耦前端应用
增量改写
设计全新的路由分发机制
使用新技术编写某一部分应用
将路由指向新的前端应用，剩下的部分任然指向旧的应用
不断添加新功能、重写模块，直至完成重写
推荐阅读
上篇：【前端架构】微前端实战
参考资料
《前端架构：从入门到微前端》
延伸阅读
▶Walkthrough007
如果觉得《【前端架构】演进式架构》对你有帮助，请点赞、收藏，并留下你的观点哦！
