为什么开发人员不喜欢更改语言版本

进步推动技术进步。但进步也有代价，通过添加新的功能和特性，开发人员社区正在不断调整构建块。这包括用于编码技术解决方案的基本语言。

当构建块改变时，技术解决方案背后的代码也必须改变。这是一项具有挑战性且耗时的工作，耗费了大量资源。但如果有其他选择呢？

问题是：阅读别人编写的代码

让我们退一步，看看开发中的一个基本挑战：编辑别人的代码。编辑您刚刚编写的或几周前编写的代码就可以了。但是编辑几年前编写的代码#8211，别管别人的代码——那是另一回事。

内部代码风格的规则可以有所帮助，但变量和函数总是有奇怪的命名约定，或算法的不寻常选择。可以说，程序员阅读代码的能力是一项关键技能；但这对每个人来说都很难。

开发人员将编辑旧代码的过程称为“重构”，这是一个通常会引入新错误或性能问题的过程。这就是为什么，返回并编辑旧代码，嗯#8211，这是大多数开发团队最不愿意做的事情，尤其是当现有的代码库运行稳定并完成其工作时。

这确实令人头痛，但有时别无选择

重构是每个开发人员都希望尽可能长时间避免的事情，因为这感觉像是浪费时间。尽管如此，由于各种原因，开发人员必须不时进行重构，最常见的原因之一是开发人员构建块的更改。

这包括对用于构建软件的编程语言的更改，这不可避免地会随着时间的推移而演变。一种语言的新版本在引入新特性的同时，往往会贬低旧的做事方式。如果开发人员不采用新的语言版本，他们将被排除在新的功能集之外。

然而，现有代码通常需要调整才能在新版本的语言上运行，这意味着一个重构过程。这就是难题：要采用新的、更高级的语言版本，开发人员需要重构，在这一过程中，他们将花费大量精力#8211，打破了各种意想不到的事情，在运行正常的应用程序中引入了新的bug。

更糟糕的是，单靠重构并不能带来新语言版本的优势，相反，您需要重新开发代码库以获得改进。否则，尽管调整了代码以适应新的语言版本，但您还是回到了以前的状态：一个在新的语言版本上运行的代码库，但没有新的功能。

供应商通常会让最终用户来处理

这看起来似乎毫无意义，但随着技术变革的稳步推进，在这件事上往往别无选择，让您的技术合作伙伴为您选择。

假设我们刚刚从Python 2.7迁移到Python 3.0。如果你在内部开发应用程序，你完全可以控制，可以改变，也可以不改变。另一方面，开发人员很可能会决定让事情顺其自然。如果应用程序是为Python 2.7开发并在其上运行的，那么开发人员只需将其保留在–；并告诉用户一个应用程序是为Python 2.7开发的，不支持其他版本。

它会让用户陷入困境#8211，继续使用旧版本的Python 2.7来适应应用程序，留下进度，或者切换到Python 3.0，这样可能会导致与应用程序的一系列不兼容。

最终结果是：存在重大安全风险

编程语言（及其分类库）也不能幸免安全漏洞。当这些漏洞出现时，开发人员可能会强制您进行语言版本升级。

但是这些升级并不局限于简单的bug修复——它们将带来对语言结构的抨击，并引入新的结构，这将迫使开发人员对现有代码进行更改，同样也会带来所有潜在的问题。

当您考虑到包含的库的复合效应时，情况会变得更糟。语言更改后，这些库也必须更新；但是，如果其中一个正在使用的库没有被其作者更新，那么开发人员在将其余代码升级到最新版本后将无法使用它，这再次导致更多的代码编写。

这个故事与我们在整个技术世界看到的情况类似，因为陈旧而脆弱的积木为网络攻击敞开了大门。然而，也出现了一些好消息。

有更好的解决方案吗？

以不支持的操作系统为例。在过去，当一个操作系统生命周期结束时，唯一的选择是升级到一个更新的操作系统#8211；重大投资，充满风险。最终的结果是，许多组织甚至在关键工作负载上也依赖于未修补、不受支持的操作系统。如果您没有更新的应用程序，因为开发人员不会重构旧的代码库，那么您就无法将应用程序移动到不支持旧版本语言的新操作系统，从而破坏应用程序。

值得庆幸的是，这种情况发生了变化，因为许多Linux操作系统现在都实现了生命终止支持，这意味着企业可以花时间从不受支持的操作系统迁移到有官方供应商支持的操作系统，而不必冒任何安全风险。

语言版本可以做类似的事情吗？使用最新的安全补丁有效地“升级”语言运行时，同时不改变特定语言版本或库的工作方式，从而消除重构的需要？

重复操作系统所取得的成果，并将其应用到语言版本中，将为开发人员提供巨大的喘息空间，减少持续重构的需要。反过来，工作负载安全可靠运行的可能性更高。

有可能吗？那么，操作系统所取得的成就可以扩展到其他领域。注意这个地方。