【技术】【开发者成长】升级遗留代码的最佳实践 |美好，一直在身边|编程语言|Ruby|

【【技术】【开发者成长】升级遗留代码的最佳实践】

本文插图
在传统企业甚至互联网企业中往往存在大量的遗留代码，这些遗留代码大多都能够正常工作，有的可能还运行着关键业务或者持有核心数据。但是，大部分遗留代码通常经常存在技术陈旧、代码复杂、难以修改等特点。随着时间的推移，遗留代码的维护和管理的成本越来越大。在全面转型微服务的今天，这些遗留代码该如何处理呢？Tomasz Kania-Orze? 为我们阐述了升级遗留代码的最佳实践，我相信，这篇文章对于拥有大量遗留代码的企业 / 组织很有借鉴意义。
“我在 Ruby on Rails 上有一款可以追溯到 2011 年的应用，在过去五年来没有添加任何新功能。而且它现在运行死慢死慢的，随着我们用户群不断地增长，它已经几乎不能提供服务了。您能帮我们解决这个问题吗？”
这是我在 Monterail 的客户那儿遇到的最常见的情景之一。这种难以维护且存在安全漏洞的遗留代码，对于必须使用它的企业，以及必须处理它的开发人员（比如我们）来说，真不啻噩梦一场。在我担任软件工程师十年左右的时间里，有过很多机会让我得以观察一些开发人员为了更新 Web 应用程序中的遗留代码而进行的技术转变，这些技术转变有成功，也有失败。例如，这可能意味着，从某个框架的版本 2 升级为版本 6 ，或者从 Ruby 变更为 Python ，或者从单体应用转变为微服务架构，或者从手工构建更改为持续交付。为了完成一次无痛（或至少不那么痛苦）更新，你必须确定进行更改是否有必要，确定最合适自己的方法并承诺长期践行。
应该何时进行变更？糟糕的性能是做出技术变更的原因。另一个原因就是你所使用的技术的普及程度逐渐或突然下降了。毕竟，如果市场上能够支持你工作的开发人员越来越少，那么你的技术存在被封闭的风险就越来越大。有些人早在 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 年从单体架构应用转向微服务，使不同的团队能够以更快的速度交付功能。
应该如何进行变更一旦确定你正在开发的产品需要升级，那么就是时候对变更方向做出明智的决定了。代码一旦编写就会成为遗留代码，没有人能保证你当时编写所用的技术在未来不会失去支持或变得过时。（安息吧， AngularJS 。）因此，变更应该支持未来的灵活性。以下是一些选项：