在传统企业甚至互联网企业中往往存在少量的遗留代码，这些遗留代码大多都可以正常任务，有的能够还运转着关键业务或许持有中心数据。但是，大部分遗留代码通常常常存在技术陈旧、代码复杂、难以修正等特点。随着时间的推移，遗留代码的维护和管理的成本越来越大。在片面转型微效劳的明天，这些遗留代码该如何处置呢？Tomasz Kania-Orzeł 为我们阐述了晋级遗留代码的最佳实际，我置信，这篇文章关于拥有少量遗留代码的企业 / 组织很有自创意义。

“我在 Ruby on Rails 上有一款可以追溯到 2011 年的运用，在过去五年来没有添加任何新功用。而且它如今运转死慢死慢的，随着我们用户群不断地增长，它曾经简直不能提供效劳了。您能帮我们处置这个成绩吗？”

这是我在 Monterail 的客户那儿遇到的最常见的情形之一。这种难以维护且存在安全破绽的遗留代码，关于必须运用它的企业，以及必须处置它的开发人员（比如我们）来说，真不啻噩梦一场。在我担任软件工程师十年左右的时间里，有过很多时机让我得以察看一些开发人员为了更新 Web 运用顺序中的遗留代码而停止的技术转变，这些技术转变有成功，也有失败。例如，这能够意味着，从某个框架的版本 2 晋级为版本 6，或许从 Ruby 变更为 Python，或许从单体运用转变为微效劳架构，或许从手工构建更改为继续交付。为了完成一次无痛（或至少不那么痛苦）更新，你必须确定停止更改能否有必要，确定最适宜本人的办法并承诺长期践行。

1. 应该何时停止变更？

蹩脚的功用是做出技术变更的缘由。另一个缘由就是你所运用的技术的普及水平逐渐或突然下降了。毕竟，假设市场上可以支持你任务的开发人员越来越少，那么你的技术存在被封锁的风险就越来越大。有些人早在 2010 年就用 Backbone 构建了他们的运用顺序，如今却在努力处置“模型 - 视图 - 控制器”的成绩，而其别人都在运用基于组件的框架，如 React 或 Vue 等。假设你选择的框架正在失掉积极的支持，那么风险就会更大。还记得 AngularJS 吗？2018 年 7 月，它就进入了长期支持阶段，这意味着 Google 不会再兼并新的功用或修补顺序，哪怕是一个庞大的打破性改动。

译注：“模型 - 视图 - 控制器”（Model–view–controller，MVC），是是软件工程中的一种软件架构形式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。MVC 最早由 Trygve Reenskaug 在 1978 年提出，是 Xerox PARC 在 20 世纪 80 年代为顺序文语 Smalltalk 发明的一种软件架构。MVC 的目的是完成一种静态的程式设计，使后续对顺序的修正和扩展简化，并且使顺序某一部分的重复应用成为能够。除此之外，MVC 经过对复杂度的简化，使顺序结构愈加直观。

当你的技术在人力或机器成本方面过于低效、过于昂贵，这不只是发起技术变更的一个好时机，而且也能够是你在技术变得不可挽回之前修复它的最后时机。你永远不会想到达这样的境地：创立一个新功用是完全不可行的。欧洲电子商务公司 Zalando 正努力快速扩展其单体 PHP 运用顺序，却 无法以快速或高效的方式提供新功用。这促使他们在 2016 年从单体架构运用转向微效劳，使不同的团队可以以更快的速度交付功用。

2. 应该如何停止变更

一旦确定你正在开发的产品需求晋级，那么就是时分对变更方向做出明智的决议了。代码一旦编写就会成为遗留代码， 没有人能保证你事先编写所用的技术在未来不会失掉支持或变得过时。（安息吧，AngularJS。）因此，变更应该支持未来的灵敏性。以下是一些选项：

选项一：大爆炸式的重写

第一个也是最清楚的选项，就是大爆炸式的重写：从头末尾更改代码库，并在一次转换中切换一切用户。但是，完全重写是十分耗时的，而且必然也会产生相当庞大的成本。你也有能够最终失掉的是一款在几个月甚至几年内都不适宜发布的运用顺序，并且在这个进程完毕之前，你都无法看到最终结果。另外，运用顺序越大，开发者在重写进程中提供维护和添加新功用的难度就越大。假设有文档和技术知识的话，向大型代码库添加新功用就像在公园里散步一样复杂。若没有这些的话，要做到这些，真的很难。

选项二：凤凰涅槃

第二个选项是在现有代码库中添加运用新技术构建的新功用。理想状况下，你不应该触及旧技术，而应该将一切新功用分分开来。但不幸的是，这样的原始结果相当稀有：新功用简直总是需求与旧功用集成。这也需求一个详细的方案，由于事情很复杂，没有缜密方案的话很难做好。在复杂的架构中创立新的组件，需求少量关于遗留运用顺序中组件运转状况的信息。你需求一个宽广的视角，重新旧两个角度看待这项技术。

运用单体运用顺序，你可以在独自部署的新代码库中创立新功用，同时运用与新代码和遗留代码交互的单个数据库来存储数据。这个处置方案看起来很复杂，但它能否取得长期成功，要取决于你的承诺能否安如磐石。（特别是当你的全体系统遭到机器功用或并发性成绩的影响时，就需求思索这些成绩。）例如，假设你的单体运用顺序末尾取得更多的用户，那么，单个数据库能够会成为瓶颈。（另一方面，云端中的数据库可以扩展。）由于原始代码库的长期软弱性，特别是思索到潜在的安全破绽或 bug，这种架构并不能耐久。实践上，让过时的代码保持原样就意味着你在等候它最终永远失败。

选项三：混合办法

重写整个代码库是一个极端的想法，而且往往思索不周。在旧代码库上添加新功用更可行，但会带来严重的反作用，例如，假设你的遗留代码是基于较旧的框架版本，那么就会出现安全成绩。那么，还有什么事情是你可以做的，而且不那么昂贵，或许不那么风险的？ 你还有其他选择吗？

我引荐一种混合办法。这一选项，就像大爆炸式重写一样，也需求对整个旧代码停止变更。但与第一种选项不同的是，重写应该是在一段时间内展开（比如说几年），以最大限制地增加技术债务和财务成本。这种渐进式办法将基于你的愿景，这一点至关重要。你需求知道首先要改动什么：有些功用是中心的，对业务至关重要，而其他功用则更多的是扮演辅佐角色。有了明白的目的，在多个层面上任务就会变得更容易。例如，你能否依然方案在这个转换进程中发布一项新功用？假设是这样的话，你就需求在方案中思索到这一点。假设没有明晰的路途图，你的代码最终将会变得一团糟，这将会使开发者更难了解。

(责任编辑：admin)