关于遗留代码，你应该停止相信的 5 个误区

如果你曾经打开过一个代码库，然后立刻低声惊呼“糟了……”，那么这篇文章就是为你准备的。
多年来，我与无数面临代码迁移的开发者进行过交流，他们都在问着同样的问题，分享着同样的挫败感。我突然意识到：我们并非在与遗留代码本身作斗争，而是在与围绕着它的种种迷思作斗争。

昨天我在JS Poland 大会上做了关于将旧前端迁移到现代工具的不同策略的演讲。哇——真是精彩的一天！
感谢所有到场的朋友。我玩得很开心，也希望你们有所收获（或者至少喜欢我那些关于“古老代码考古”的笑话😄）。

受演讲后所有讨论的启发，我决定写下关于遗留系统的最大误区——我们作为开发人员经常重复的那些话，以至于它们听起来像是普遍真理……即使它们并非如此。

让我们来逐一揭穿它们👇

误区一：“传承意味着古老的或异域风情的。”

不。传统技术并不一定是指上世纪90年代那些神秘的、被人遗忘的技术。

有时候，它只不过是……昨天的主流而已。

• 一个略微过时的Angular版本
• 一个包含大量类组件的 React 代码库
• 一个“仍然有效，所以不要动它”的 Webpack 3 配置

遗留问题并非指工具的年代久远，而是指工具与当前环境的不匹配。当团队、生态系统或业务发展到新的阶段，而代码库却没有相应更新时，该工具就变成了遗留工具。

误区二：“历史遗留问题是前任团队的错。”

这条总是让我发笑。

你几乎永远不会知道你继承的代码背后的全部故事：

• 或许这个项目已经停滞了6年。
• 或许团队缺乏足够的经验或时间来进行迁移。
• 或许那个什么都懂的人在2018年离开了公司。（我们都认识这样的人。）

指责别人很容易，理解事情的来龙去脉却更难——但也更有成效。

误区三：“迁移只是开发人员的执念。”

我希望如此😅

历史遗留问题可能会在不知不觉中损害企业：

• 安全问题
• 性能问题
• 不断上涨的维护成本
• 由于每个新功能都像是在拆除炸弹，所以交付速度放缓。

迁移不是为了面子，而是为了风险管理。

误区四：“大爆炸式重写总是一种反模式。”

大爆炸式重写法名声很差——通常是有原因的。
但有时，它们却是最便宜、最快捷的解决方案。

如果应用程序规模小、功能独立且并非关键任务型应用，那么可以进行彻底的重写：

• 更简单
• 更安全
• 更快
• 而且比耗时数年重构旧代码要轻松得多。

并非每次迁移都需要像 Netflix 那样的多阶段大工程。

误区五：“绞杀式编织法是唯一正确的编织方法。”

绞杀者迁移非常适合大型、复杂的应用程序。但它也存在一些缺点：

• 这需要时间（很多时间……）
• 你将面临永无止境的迁移。
• 你的团队需要同时掌握两种技术。
• 新旧之间的界限可能会变得模糊不清。

它只是一种工具，而不是一种宗教。

有时候，绞杀者（Strangler）就足够了。
有时候，宇宙大爆炸（Big Bang）就足够了。
有时候，你需要的是两者的结合体。

真正的技巧在于根据自身限制条件选择合适的策略。

最后想说的

遗留代码并非失败，它只是软件自然生命周期的一部分。
每个代码库最终都会变成遗留代码——包括你今天正在编写的这个 😉

重要的是要了解各种权衡取舍，选择正确的迁移策略，并避免那些让传统系统看起来比实际情况更可怕的误解。