如何处理遗留代码？
极客时间编辑部
讲述：丁婵大小：7.18M时长：05:14
在传统企业甚至互联网企业中往往存在大量的遗留代码，这些遗留代码大多都能够正常工作，有的可能还运行着关键业务或者持有核心数据。但是，大部分遗留代码经常存在技术陈旧、代码复杂、难以修改等特点。随着时间的推移，遗留代码的维护和管理成本越来越大。该如何处理呢？
日前，DevOps 工程师托马斯·卡尼亚奥兹（Tomasz Kania-Orzeł）阐述了升级遗留代码的几个最佳实践。以下为 InfoQ 编译内容。
应该如何进行变更？
代码一旦编写就会成为遗留代码，没有人能保证你当时的编程技术在未来不会失去支持或变得过时。因此，变更应该考虑未来的灵活性。以下是一些变更选项。
选项一：大爆炸式的重写
从头开始更改代码库，并在一次转换中切换所有用户。但是，完全重写是非常耗时的，而且会产生相当巨大的成本。你也有可能得到一款在几个月甚至几年内都不适合发布的应用程序，并且在这个过程结束之前，你都无法看到最终结果。另外，应用程序越大，开发者在重写过程中提供维护和添加新功能的难度就越大。
选项二：凤凰涅槃
新功能几乎总是需要与旧功能集成，使用单体应用程序，你可以在单独部署的新代码库中创建新功能，同时使用与新代码和遗留代码交互的单个数据库来存储数据。这个解决方案看起来很简单，但它能否取得长期成功呢？如果你的单体应用程序开始获得更多的用户，那么，单个数据库可能会成为瓶颈。由于原始代码库的长期脆弱性，特别是考虑到潜在的安全漏洞或 Bug，这种架构并不能持久。
选项三：混合方法
这种方法不那么昂贵，或者不那么危险。 就像大爆炸式重写一样，也需要对整个旧代码进行变更。但混合方法的重写应该是在一段时间内展开（比如说几年），以最大限度地减少技术债务和财务成本。你需要知道首先改变什么：有些功能是核心的，对业务至关重要。
这种方法关乎未来的可扩展性，而且它最容易使用微服务来实现。假设你的遗留代码库是新的微服务生态系统中的一个元素，当然，它太过于庞大，过于复杂，不可能是真正的微服务，但它可以像微服务一样与新功能进行通信。为了处理这项安排，你需要创建 API 或“桥”这样的接口，以允许遗留代码与新技术进行通讯。当你以单独的微服务形式添加新功能时，它们将会一点一点地吞噬遗留代码的业务逻辑。虽然你可以通过向遗留的单体应用程序添加新功能来实现类似的功能，但此举可能会造成技术债务，并失去灵活性。
几乎所有的解决方案都有副作用，包括这种方法。但是你需要知道如何将副作用最小化。对于 Web 应用的前端，反向代理可以缓和这一变更带来的副作用。使用这种方法，你甚至可以在不触及遗留软件的情况下，替换 Web 应用中为单个 URL 提供服务的逻辑。但这种技术有其自身的要求，例如，如果你有用户登录的话，就应该维护页面之间的状态。我们始终需要存储状态，但在这个解决方案中，我们需要在两个应用之间移动或共享状态。这很难维护，但你还是可以得到更具弹性的基础设施。
更复杂的更改需要对基础设施进行改进，比如，创建一个前端服务器层，你可以从其中呈现来自不同源的应用程序片段，如上面的微服务示例，基于 XML 的标记语言 ESI（Edge Sides Includes）可能适合这项任务。为了确保你的应用在用户群增长时性能稳定，请创建负载均衡器和基于上下文的独立数据库，这些数据库在微服务或宏服务中单独使用。
创造一个能够支持这种安排的灵活环境也是一个挑战。转移到微服务时，你只需在基础设施上投资一次，但你将需要进一步支持这种架构的维护。尽管如此，它可能仍然比重写所有代码要便宜得多。
当然，这种混合方法并不是世界上唯一可行或正在使用的选项。但是，代码库的增量更改最终导致了完全重写，你得以使用工作代码，从而使业务保持安全，同时，微服务使不同团队能够独立地交付不同的新功能，提供了一个为长期使用而设计的过程和架构。
以上就是今天的内容，希望对你有所帮助。
原文链接：
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(3)
- 最新
- 精选
小斧《代码清洁之道》建议读一读。2
Arvin一般公司都是不得不在遗留的痛苦上继续前行
leslie大致思路方式都一样：生活中工作，工作中生活；答案一切尽在其中。
收起评论