「阿里云云栖号」【开发者成长】升级遗留代码的最佳实践在传统企业甚至互联网企业中往往存在大

文章图片
在传统企业甚至互联网企业中往往存在大量的遗留代码，这些遗留代码大多都能够正常工作，有的可能还运行着关键业务或者持有核心数据。但是，大部分遗留代码通常经常存在技术陈旧、代码复杂、难以修改等特点。随着时间的推移，遗留代码的维护和管理的成本越来越大。在全面转型微服务的今天，这些遗留代码该如何处理呢？TomaszKania-Orze?为我们阐述了升级遗留代码的最佳实践，我相信，这篇文章对于拥有大量遗留代码的企业/组织很有借鉴意义。
“我在RubyonRails上有一款可以追溯到2011年的应用，在过去五年来没有添加任何新功能。而且它现在运行死慢死慢的，随着我们用户群不断地增长，它已经几乎不能提供服务了。您能帮我们解决这个问题吗？”
这是我在Monterail的客户那儿遇到的最常见的情景之一。这种难以维护且存在安全漏洞的遗留代码，对于必须使用它的企业，以及必须处理它的开发人员（比如我们）来说，真不啻噩梦一场。在我担任软件工程师十年左右的时间里，有过很多机会让我得以观察一些开发人员为了更新Web应用程序中的遗留代码而进行的技术转变，这些技术转变有成功，也有失败。例如，这可能意味着，从某个框架的版本2升级为版本6 ，或者从Ruby变更为Python ，或者从单体应用转变为微服务架构，或者从手工构建更改为持续交付。为了完成一次无痛（或至少不那么痛苦）更新，你必须确定进行更改是否有必要，确定最合适自己的方法并承诺长期践行。
应该何时进行变更？糟糕的性能是做出技术变更的原因。另一个原因就是你所使用的技术的普及程度逐渐或突然下降了。毕竟，如果市场上能够支持你工作的开发人员越来越少，那么你的技术存在被封闭的风险就越来越大。有些人早在2010年就用Backbone构建了他们的应用程序，如今却在努力解决“模型-视图-控制器”的问题，而其他人都在使用基于组件的框架，如React或Vue等。如果你选择的框架正在失去积极的支持，那么风险就会更大。还记得AngularJS吗？2018年7月，它就进入了长期支持阶段，这意味着Google不会再合并新的功能或修补程序，哪怕是一个微小的突破性改动。
译注：“模型-视图-控制器”（Model–view–controller ， MVC），是是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。 MVC最早由TrygveReenskaug在1978年提出，是XeroxPARC在20世纪80年代为程序语言Smalltalk发明的一种软件架构。 MVC的目的是实现一种动态的程式设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外， MVC通过对复杂度的简化，使程序结构更加直观。
当你的技术在人力或机器成本方面过于低效、过于昂贵，这不仅是发起技术变更的一个好机会，而且也可能是你在技术变得不可挽回之前修复它的最后机会。你永远不会想达到这样的地步：创建一个新功能是完全不可行的。欧洲电子商务公司Zalando正努力快速扩展其单体PHP应用程序，却无法以快速或高效的方式提供新功能。这促使他们在2016年从单体架构应用转向微服务，使不同的团队能够以更快的速度交付功能。
应该如何进行变更一旦确定你正在开发的产品需要升级，那么就是时候对变更方向做出明智的决定了。代码一旦编写就会成为遗留代码，没有人能保证你当时编写所用的技术在未来不会失去支持或变得过时。（安息吧， AngularJS 。）因此，变更应该支持未来的灵活性。以下是一些选项：
选项一：大爆炸式的重写
第一个也是最明显的选项，就是大爆炸式的重写：从头开始更改代码库，并在一次转换中切换所有用户。但是，完全重写是非常耗时的，而且必然也会产生相当巨大的成本。你也有可能最终得到的是一款在几个月甚至几年内都不适合发布的应用程序，并且在这个过程结束之前，你都无法看到最终结果。另外，应用程序越大，开发者在重写过程中提供维护和添加新功能的难度就越大。如果有文档和技术知识的话，向大型代码库添加新功能就像在公园里散步一样简单。若没有这些的话，要做到这些，真的很难。