在我们浪费时间谈论大型机的同时，技术日新月异的威胁隐约可见。

> Photo credit Simon Claessen.

每当收到采访请求或邀请谈论我在进行遗留现代化方面的工作时，大家都会想谈论大型机和COBOL。 我的假设是，我将为其他工程师讲一些关于旧系统繁重的战争故事，这些工程师不需要担心这些东西，因为他们的职业集中在现代技术上。

的确，当我开始使用遗留系统时，我也被最古老的程序吸引到了里普利的信不信由你公司。 发掘和剖析旧系统的快感，找出大多数程序员从未听说过的被遗忘的语言，更不用说与之交互了。 我一直对低级语言和系统着迷，这种魔术将电压变化转化为数学和设计中的抽象。 但是最近，我对即将到来的旧世界末日以及如何减缓新技术的技术债务水平越来越感兴趣。

启示录并不是最后一个婴儿潮一代COBOL程序员的死亡。 老实说，危机已经过去了。 当人们谈论旧系统的威胁时，他们喜欢发布有关旧COBOL程序员的统计数据。 例如，在2006年，COBOL程序员的平均年龄为55岁。这听起来很糟糕。 许多关键员工即将退休！ 谁走了，谁来照顾他们的系统？

平均数可能会产生误导。 在同一调查中，有52％的程序员是45-55，而34％是35-45。 但更重要的是，八年后，所有这些55岁的程序员都应该退休了Micro Focus对COBOL程序员和高管的调查，这使得COBOL程序员的平均年龄再次达到55岁。 他们的2019年调查的平均值为50。

实际上，COBOL程序员的平均年龄已经稳定了几十年。 当我父亲从事Y2K虫害工作时，他处于40年代末至50年代初。 他的同事们年龄相仿。 每当我看到人们对COBOL社区的时代大有作为时，我都会想起美国的obobist Blair Tindell写的关于古典音乐社区的东西：

关于老年听众的恐惧被放错了地方，而忽略了平均听众年龄在四十年代后期徘徊了一段时间。 人们等到中年才开始参加交响乐团是合乎逻辑的。 随着孩子的成长，学费的增加，休闲时间的增加，音乐会非常适合成熟的婴儿潮一代丰富的生活方式，品味和收入。

关于COBOL也可以说类似的话。 与60年代，70年代和80年代的年轻程序员不同，当今的年轻程序员没有大学大型机可玩。 如果大学还拥有大型机，那将是行政部门的主力军，对学生项目而言至关重要。 年轻的程序员不能选择学习COBOL。 即使他们完成了数百个（甚至说成千上万个）COBOL工作，也不是入门级的工作。

COBOL程序员的平均年龄稳定的原因很可能是因为COBOL程序员在进入职业生涯后期才转向COBOL之前，已经发展了他们在其他语言中的经验和专长。

人们担心旧的COBOL程序员，因为他们认为最后一个COBOL程序员死亡时，他们的程序将无法维护。 这是一个合理的问题，但是大多数人会惊讶地发现，无法维护的遗留代码的威胁比他们认为的要紧密得多，并且不涉及大型机。

64％的Java应用程序卡在Java 8上

如果您保持评分，那么Java的最新版本是14。Java8的生命周期应该在2019年。

Java 9引入了一些结构性更改，以使Java更具模块化，因此对于嵌入式系统更可行。 从Java 8迁移到Java 9不是升级，而是完全迁移。 Java 9使JDK内部API不可访问，除其他外，它删除了一些工具和方法，并且向模块化结构的转变要求对依赖项进行更改。 换句话说，从Java 8迁移到Java 9可能意味着必须重写许多代码。

因此，Snyk在2020年调查的生产应用程序中有一半以上仍在Java 8上运行。

Python 2

当然，真正重大迁移的最终升级是从Python 2到Python 3的过渡。与Java 8一样，Python 2一直存在，因为向Python 3的迁移既需要重写您拥有的代码，又要从所有代码中删除Python 2 您的依赖项。 尽管像本杰明·彼得森（Benjamin Peterson）的六个工具使这项任务变得更加轻松，但是依赖关系远不止软件包和库。 运行代码的平台也是一个依赖项，并且平台响应速度很慢。 尽管Python是一种非常流行的脚本工具，但AWS Lambda直到2017年发布3.6才一年，直到2017年才支持Python 3。 Salt于同年推出了对Python 3的支持。 一年后，Ansible支持它，大约在Python 3最初发布大约十年后。

很难说世界上还剩下多少Python 2。 Jetbrains估计只有10％，在150个不同国家/地区拥有24,000名受访者，这可能是一个准确的数字。 Python 2的问题可能不是它太多，而是它仍然存在。 根据Jetbrains的说法，Python 2仍在为自己赚钱的机会让Python 3受益的地方是DevOps /自动化，测试和网络编程。 要使各种风格的Linux完全致力于Python 3，这是一个巨大的挑战。 战斗还没有结束，每个喜欢Mac的pythonista都知道，由于MacOS内部工具的缘故，Apple计算机仍将Python 2.7作为其默认Python版本。

每个人都讨厌jQuery，却无所不在

依赖的另一面是jQuery。 由于依赖关系，从jQuery迁移并不困难，这是困难的，因为还有很多其他事情都依赖jQuery。

当Twitter Bootstrap最终在2019年将jQuery作为依赖项删除时，这仅仅是因为他们将jQuery的源代码直接复制并粘贴到了Bootstrap中。 即使这样，整个项目从开始到结束也花费了两年多的时间。

jQuery是其自身成功的受害者。 它的简单语法非常受欢迎，以至于其他框架甚至本机JS也开始采用它。 最重要的是，jQuery所提供的许多交叉兼容的传统技术最终都已经退役（从Internet Explorer看）。 我个人认为关于jQuery的担忧有些夸张，但我不是JavaScript专家。 反对jQuery的运动似乎已由该框架与当前的MVC JavaScript框架React之间的冲突拉开帷幕。

但是，就像所有技术上的神圣战争一样，反对重复选择越多越好。 在某些方面，我认为jQuery的故事与COBOL的故事最相似，因为有关它的头条新闻无处不在，并暗示由于其他技术现在可以做同样的事情，因此那些其他（较新的）技术必须更好。

深度而非年龄

有许多因素使遗留系统难以维护。 程序员从事维护工作的年龄并不是其中之一。 的确，机构内存的丢失很重要，而最了解系统的程序员离开机构内存的时间也随之而来。 但这不是旧技术独有的问题。 组织因偷猎人员而失去机构记忆的频率与退休时一样（可能更频繁）。

通过建立可培养COBOL人才的管道，可以用COBOL精通的可用工程师数量有限的事实解决了一个更便宜，更容易的问题。 IBM通过其Master Mainframe计划在这一领域非常活跃。 COBOL程序员是一种枯竭的有限资源，这根本不是真的。

以我的经验，我必须说，每当COBOL系统发生故障时，几乎从来没有COBOL导致系统崩溃。 我已经看到硬件故障，支持或以其他方式与COBOL集成的非COBOL系统出现问题，由于无法很好地记录COBOL代码以及工程人员需要找出更改方法等原因而导致添加新功能的延迟。 但是我并没有看到很多事件表明系统本身在COBOL中是一个问题。 这并不是说没有充分的理由要摆脱COBOL。 我只是不愿意同意民间社会在60年来不能继续使用数百万行COBOL。 当然可以。

另一方面，Java 8和Python 2则要严重得多。 当系统无法摆脱报废技术时，它们会错过安全更新，性能增强和新功能。 系统停留在自己的技术债务中的时间越长，在它们之上构建的事物越多，遗产就越根深蒂固。

当我们似乎在谈论关于遗留代码日益增长的威胁的讨论以COBOL开始和结束时，我们给程序员带来了伤害。 整个软件工程师的职业生涯都是通过将应用程序（除了应用程序的最独特方面之外）的所有方面都外包给他们无法监控的库，插件和模块，更不用说更新了，从而使问题变得更糟。

框架的兴起

如果可以将Wikipedia视为权威资料，那么在90年代，当人们可以使用大量计算机，但抽象程度仍然相对较低时，围绕开发全新编程语言的活动就达到了顶峰。 互联网通过使更复杂的分布式系统成为现实，以及通过扩大安全问题的爆炸半径而改变了这一点。 由于需要更好的性能和更好的安全性，因此现代机器上新语言的MVP变得相当复杂。 聪明的计算机科学家不再能够构建概念宠物语言的证明，而期望将其应用于现实世界中的问题以推动其发展。 编程语言有望为程序员处理大量复杂的任务。

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

从本质上讲，框架只是给定一个公共接口的精选的依赖项集合。 没错，框架使软件开发更快，但是它们也剥夺了开发人员维护代码的能力。 工具方面的进步降低了软件开发的速度，不可避免地加深了普通软件项目的依赖树。

以Node.js为例。 Node是一个有趣的框架，它使得可以在服务器端运行JavaScript成为可能，但它也引入了（作为依赖项）一个称为NPM的漂亮的小程序包管理器。 之前曾经有过软件包管理器，而NPM不一定是最好的软件包管理器，但是它可以通过从软件包管理器中吸取一些经验教训来提供更好的用户体验。 默认情况下，它在本地而非全局安装东西。 命令行从一开始就被设计为与软件包存储库集成，因此创建和发布新软件包非常容易。

结果，NPM上依赖树的平均深度为4.39包，而可比较的包管理器（在本例中为PyPi）上的平均深度为1.7。 Python开发人员本质上不比JavaScript开发人员负责。 JavaScript缺乏良好的核心库，并且它作为玩具语言在一周内进行设计和实现的历史使其为开发可简化其粗糙边缘的框架而成熟。 有很多npm软件包可以执行一些小的愚蠢的事情，而其他语言则具有内置功能。 NPM使共享变得容易。

> Package dependencies NPM -vs- PyPi. Truly scary numbers

但是，如果ECMA决定以Java 9和Python 3尝试解决其语言的结构性问题的方式来解决JavaScript的某些缺陷，将会发生什么？ npm上大约60％的软件包在一年或更长时间内未更新。 尽管缺乏维护，但这些软件包仍被下载数十亿次。

ECMA在其"一个JavaScript"政策中承认的一个现实：

但是，如何摆脱版本控制呢？ 通过始终向后兼容。 这意味着我们必须放弃我们的一些野心。 清理JavaScript：我们无法引入重大更改。 向后兼容意味着不删除功能也不更改功能。 这个原则的口号是："不要破坏网络"。

当我们谈论长期维护健康和安全的技术系统时，这比COBOL程序员的年龄所面临的威胁要大得多。 但是，当我们谈论遗产时，我们不会谈论这些问题。

总结：战略胜于速度

依赖关系是必然的弊端，但使用依赖关系不必将项目谴责为遗留地狱。 我们需要开始将长期维护目标纳入有关技术选择的对话中。 JavaScript框架创建了深层的依赖树，是的，但是即使NPM是为满足后端语言的需求而开发的，但80％的活动都是与前端相关的。 我们扔掉前端，并在所有该死的时间内重建它们。 设计界的普遍智慧是，网站大约每三年进行一次重新设计。 因此，从遗留现代化的角度来看，具有较大依赖关系图的React前端与具有相同大小的依赖关系图的Node应用程序更深地埋在体系结构中相比，不再需要担心。

换句话说，我们需要开始批判性地思考给定技术可以持续多长时间，并问自己在构建技术时所做的选择是否会使以后难于删除。 我们再也无法承受等待何时出现更好的情况。 我们必须假设，最终会出现更好的情况。

最后，我们需要重新调整对话的重点，并停止妖魔化仅适用于老年人并由老年人编程的技术。 世界上很大一部分的COBOL都对COBOL表现良好。 确实存在的问题也可以在2002年构建的Web应用程序中找到。COBOL是古老的事实不重要，它分散了生命周期结束后不断增长的代码生态系统的注意力。

(本文翻译自Marianne Bellotti的文章《Old Code Gets Younger Every Year》，参考：)