旧代码一年比一年年轻

每当我收到采访请求，或者被邀请谈论我在遗留现代化方面的工作时，每个人都想谈论大型机和COBOL。我们的假设是，我将为其他工程师讲述一些关于旧系统的苦差事的精彩战争故事，他们不需要担心这些事情，因为他们的职业生涯集中在现代技术上。

诚然，当我开始使用遗留系统时，我也被里普利最古老的程序中的“信不信由你”所吸引。挖掘和剖析越来越老的系统，找出大多数程序员从未听说过的被遗忘的语言的刺激，更不用说与之交互了。我一直对低级语言和系统着迷，这种魔力将电压的变化转化为数学和设计中的抽象。但最近，我对即将到来的遗产启示录以及如何减缓新技术(-er)技术债务水平的上升更感兴趣。

遗产启示录并不是婴儿潮时期最后一位COBOL程序员的死亡。老实说，这场危机来来去去。当人们谈论旧系统的威胁时，他们喜欢炫耀COBOL程序员的年龄。例如，在2006年，COBOL程序员的平均年龄是55岁。听起来很糟糕。很多关键员工都快退休了！他们离开后，谁来照看他们的系统？

平均数可能会产生误导。在同一项调查中，52%的程序员年龄在45-55岁之间，34%的程序员年龄在35-45岁之间。但更重要的是，8年后，当所有55岁的程序员都应该退休时，Micro Focus对COBOL程序员和高管的调查显示，COBOL程序员的平均年龄又回到了55岁。他们在2019年的调查显示，这一平均值为50。

事实上，COBOL程序员的平均年龄几十年来一直很稳定。当我父亲研究千年虫的时候，他已经40多岁了，50岁出头。他的同事年龄相仿。每当我看到人们对COBOL社区的年龄大做文章时，我就会想起美国双簧管演奏家布莱尔·廷德尔(Blair Tindell)写下的关于古典音乐社区的一些东西：

对年长听众的恐惧是错误的，忽略了一个事实，即平均观众年龄已经徘徊在40多岁左右一段时间了。对于人们来说，等到中年才开始参加交响乐是合乎逻辑的。随着孩子的长大，学费的支付，更多的闲暇时间，音乐会非常适合成熟的婴儿潮一代丰富的生活方式，品味和收入。

对于COBOL也可以说类似的事情。与60年代、70年代和80年代的年轻程序员不同，今天的年轻程序员没有大学大型机可玩。如果大学仍然有大型机，那它就是管理部门的主力，对学生项目来说太重要了。年轻的程序员没有学习COBOL的选择。即使他们这样做了，数百个-或者有人说是数千个-COBOL工作也不是入门级的。

COBOL程序员平均年龄稳定的原因很可能是因为COBOL程序员在职业生涯后期转向COBOL之前，已经在其他语言中积累了丰富的经验和专业知识。

人们担心老的COBOL程序员，因为他们认为当最后一个COBOL程序员消亡时，他们的程序将无法维护。这是一个合理的担忧，然而，大多数人会惊讶地发现，不可维护的遗留代码的威胁比他们想象的要近得多，而且不涉及大型机。

如果你在计分，Java的最新版本是14。Java8的生命周期应该是2019年。

Java9引入了一些结构变化，使Java更加模块化，因此更适用于嵌入式系统。从Java8迁移到Java9不是升级，而是完全迁移。其中，Java9使得JDK内部的API无法访问，它删除了几个工具和方法，并且向模块化结构的转变需要更改依赖项。换句话说，从Java8迁移到Java9可能意味着必须重写大量代码。

因此，Synk在2020年调查的生产应用程序中，超过一半仍然运行在Java8上。

当然，真正重大迁移的最终升级是从Python2到Python3的转换。与Java 8一样，Python2一直在徘徊，因为迁移到Python3既需要重写您拥有的代码，又需要从您的所有依赖项中消除Python2。虽然像Benjamin Peterson的Six这样的工具让这项任务变得更加愉快，但依赖关系不仅仅是包和库。代码在其上运行的平台也是一个依赖项，而且这些平台的响应速度都很慢。虽然Python是一款极其流行的脚本工具，但AWS Lambda直到2017年3.6才支持Python 3，也就是3.6发布一年之后。同年，Salt推出了Python3支持。一年后，大约在Python3最初宣布的十年后，Ansible支持它。

很难说世界上还剩下多少Python2。JetBrains估计这一比例只有10%，而且有来自150个不同国家的2.4万名受访者，这可能是一个准确的数字。Python2的问题可能不在于它的数量太多，而在于它仍然存在的地方。根据JetBrains的说法，Python2仍在与Python3竞争的领域是DevOps/Automation、测试和网络编程。事实证明，让各种风格的Linux完全致力于Python3是一个巨大的挑战。这场斗争还没有结束，每个热爱Mac的Pythonista都知道，由于MacOS内部工具的原因，苹果电脑仍然使用Python2.7作为默认的Python版本。

在依赖地狱的另一面是jQuery。由于依赖关系，从jQuery迁移并不困难，但很困难，因为很多其他东西都依赖于jQuery。

当Twitter Bootstrap最终在2019年将jQuery作为依赖项移除时，只是因为他们将jQuery中的源代码直接复制并粘贴到Bootstrap中。尽管如此，整个项目从开始到结束花了两年多的时间。

jQuery是自身成功的牺牲品。它简单的语法被证明是如此流行，以至于其他框架甚至本机JS都开始采用它。最重要的是，jQuery提供交叉兼容性的许多遗留技术终于被淘汰了(看看您的Internet Explorer吧)。就我个人而言，我认为围绕jQuery的担忧有点过头了，但我不是JavaScript爱好者。反对jQuery的运动似乎是由该框架与目前方兴未艾的MVC JavaScript框架Reaction之间的冲突拉开的序幕。

但就像所有科技领域的圣战一样，反对选择一个而不是另一个的合理论据越频繁地重复，就会变得越模糊。在某些方面，我认为jQuery的故事与COBOL的故事最相似，因为发布的关于它的标题以它的无处不在而领先，并暗示因为其他技术现在可以做同样的事情，所以那些其他(较新的)技术肯定更好。

有很多事情使得遗留系统很难维护。做维护的程序员的年龄不在其中。诚然，机构记忆的丧失很重要，最了解系统的程序员什么时候离开机构记忆也会随之而来。但这并不是旧技术独有的问题。组织对挖走员工失去机构记忆的频率与对退休的频率一样高(可能更多)。

精通COBOL的可用工程师资源有限的事实是，通过建立管道来培养COBOL人才，这个问题解决起来要便宜得多，也容易得多。IBM在这个领域非常活跃，他们的Master the Mainframe计划。COBOL程序员是一种正在枯竭的有限资源，这根本不是真的。

我不得不说，根据我的经验，每当COBOL系统崩溃时，几乎从来不是COBOL导致它崩溃。我看到过硬件故障，支持或以其他方式与COBOL集成的非COBOL系统的问题，我看到添加新功能的延迟，因为COBOL代码文档很少，工程人员需要找出如何更改它的…。。但是我没有见过很多事件，系统是用COBOL编写的，这本身就是一个问题。这并不是说没有很好的理由放弃COBOL，绝对有理由。我只是不倾向于同意公民社会不能在接下来的60年里继续运行数百万行COBOL语言。当然可以。

另一方面，Java8和Python2则是一个严重得多的威胁。当系统无法摆脱生命周期结束的技术时，它们会错过安全更新、性能增强和新功能。系统在自己的技术债务中停留的时间越长，建立在它们之上的东西就越多，遗产就变得越根深蒂固。

当我们表现得好像关于遗留代码日益增长的威胁以COBOL开始和结束的对话开始和结束时，我们对程序员是一种伤害。整整一代软件工程师的职业生涯都在把他们的应用程序除了最独特的方面之外的所有方面都外包给他们无力监控的库、插件和模块，更不用说更新了，这让问题变得更糟。

遗产启示录中真正的骑士是依赖树的深度。现代软件开发将抽象堆叠在抽象之上。如果2016年的Left-Pad事件没有证明其他什么，那么它表明，即使是经验丰富的工程师也会依赖于他们的应用程序，如果给他们提供使安装变得容易的基础设施的话。现代开发环境是一个名副其实的廉价和方便依赖的糖果商店。

如果维基百科可以被认为是一个权威的来源，那么围绕开发全新编程语言的活动在90年代达到顶峰，当时大量的人都可以使用计算机，但抽象程度仍然相对较低。互联网改变了这一点，不仅使更复杂的分布式系统成为现实，而且还扩大了安全问题的爆炸半径。要求更好的性能和更好的安全性使得现代机器上新语言的MVP变得相当复杂。聪明的计算机科学家再也不能构建概念证明宠物语言，并期望将它们应用于现实世界的问题来推动它们的进化。编程语言需要为程序员处理大量复杂的任务。

因此，尽管自90年代的辉煌时期以来，专业程序员的数量急剧增加，但这些软件专家已经从开发新语言转向开发新框架。

框架本质上只不过是给定公共接口的经过管理的依赖项集合。诚然，框架使软件开发速度更快，但它们也剥夺了开发人员维护代码的能力。降低软件开发速度的工具改进不可避免地加深了一般软件项目的依赖关系树。

以Node.js为例。Node是一个有趣的框架，它使在服务器端运行JavaScript成为可能，但它还引入了一个名为npm的漂亮的小包管理器(作为依赖项)。以前有过包管理器，NPM不一定是最好的，但它从之前的包管理器那里学到了一些经验，从而提供了更好的用户体验。默认情况下，它是本地安装的，而不是全局安装的。命令行从一开始就设计为与包存储库集成，因此创建和发布新包非常容易。

因此，NPM上依赖关系树的平均深度为4.39个包，而同类包管理器(在本例中为PyPI)的平均深度为1.7。Python开发人员本身并不比JavaScript开发人员更负责任。JavaScript缺乏一个好的核心库，而且它作为一种玩具语言的历史只用了一周时间就设计和实现了，这使得开发框架来抚平它的粗糙边缘的时机已经成熟。有很多NPM包做一些小的愚蠢的事情，而在其他语言中有一个内置的函数。NPM让分享变得很容易。

但是，如果ECMA决定修复JavaScript的一些缺点，就像Java9和Python3试图解决其语言的结构问题一样，会发生什么呢？NPM上大约60%的软件包在一年或更长时间内没有更新。尽管缺乏维护，这些软件包仍然被下载了数十亿次。

但是我们怎样才能摆脱版本化呢？总是向后兼容。这意味着我们必须放弃一些野心。清理JavaScript：我们不能引入破坏性更改。向后兼容意味着不删除功能和不更改功能。这一原则的口号是：“不破网”。

我们可以整天争论永远向后兼容的优点。问题是，JavaScript中一直固有的巨大依赖关系随着框架变得越来越流行而变得越来越糟糕。因此，解决JavaScript等语言的大量结构问题的工具也使得这些问题在较新版本的JavaScript中无法修复。

当我们谈到长期维护健康和安全的技术系统时，这比COBOL程序员时代的威胁要大得多。然而，当我们谈论遗产时，我们并没有谈论这些问题。

依赖关系是一种必要的邪恶，但使用它们并不一定要将项目定为遗留地狱。我们需要开始将长期维护目标纳入我们关于技术选择的对话中。是的，JavaScript框架创建了深度依赖树，但是即使开发NPM是为了满足后端语言的需求，它上80%的活动也是与前端相关的。我们把前额扔掉，然后一直重建。设计界的普遍看法是，网站大约每三年重新设计一次。因此，从遗留现代化的角度来看，与具有更深层次依赖图的相同大小的Node应用程序相比，具有大小依赖图的Reaction前端并不是什么问题。

换句话说，我们需要开始批判性地思考我们期望一项给定的技术能持续多久，并问问自己，我们在构建它时所做的选择是否会让它更难在以后移除。我们再也不能坐等更好的事情出现了。我们必须假设最终会有更好的东西出现。

最后，我们需要重新调整对话的焦点，停止妖魔化技术，仅仅因为技术老了，被老年人编程。世界上很大一部分COBOL在COBOL上做得很好。确实存在的问题也可以在2002年开发的webapp中找到。COBOL陈旧这一事实并不重要，它分散了人们对已经过了生命周期的不断增长的代码生态系统的注意力。

我的一个有趣的大流行项目之一就是制作稍微有点像巨人一样的工程贴纸。如果你想要一份免费的“所有软件都是垃圾”，告诉我送到哪里。