软件淹没世界

我在许多机构工作的众多优点之一就是，您可以了解有什么共同点。 到处都是这样吗？答案是肯定的！ 我看到的组织正在停滞不前，但我不确定他们是否意识到自己正在这样做。 每次您决定解决代码问题时，您都将在将来的能力中投入一部分来维护和操作该代码。 您编写网络服务来解决业务问题。 Sayit具有HTML Web UI 现在，您的代码存在安全问题，您应该评估是否需要做一些工作来解决这些问题。 人类在编写安全代码方面非常糟糕。 只要有足够的时间，其他人就会发现您服务中的安全漏洞。 这既适用于您组织编写的代码，也适用于它们使用的库，操作系统，Web服务器或…。

从浏览CVE数据库中进行选择，或者使用Snyk或类似工具查看当前的代码库。

您编写网络服务来解决业务问题。说它有一个HTML Web UI

现在，您的代码存在法律合规性问题，您应该评估是否需要做一些工作来解决这些问题。

网站可访问性的《 2010年平等法案》（英国）和《 1990年美国残疾人法案》（2010年更新）。是的，有一段时间人们在构建网站时不考虑可访问性。

英国退欧给欧盟和英国的企业带来了许多变化，软件已被改写以管理新的贸易关系，这将在一段时间内继续建立新的关系。

第三方将更改其API或工作方式。他们可能出于多种原因执行此操作：性能或其中的安全性。较旧的版本已弃用，不受支持。这些较旧的版本仍会针对它们报告新的安全问题。因此，您需要升级并修改代码以使用newAPI。

建立代码库的人们将努力保持向后兼容。但是我们仍然得到主要的版本更改，以及突破性的API更改。

大多数软件需要不断维护。在决定以这种方式解决问题时，应始终考虑构建和运行软件的成本。

以特定方式工作的团队只能负责固定数量的软件。应该管理软件的数量，否则团队将停止工作。

我有另外一篇有关Dunbar号码的帖子（目前正在酝酿中），但对于此帖子，不同规模的组织可能会有不同的选择。在一定规模下，让人们致力于开发人员的生产力并创建可提高其他团队能力的工具是有意义的。

您可以选择高级语言，并使用SaaS供应商提供的技术堆栈，而这些技术堆栈所需的时间更少。

去年，我曾打算花一个选项研究（但最终我找到了工作）。这感觉像是一个潜在的大市场。我见过许多拥有十年历史的代码库的组织，它们仍在运行不受支持的依赖项或框架版本。

作为开发人员，我熟悉锤子，并且好奇是否可以使用它。

在我曾经工作过的每个组织中，我都从各个方面看到了这个问题。

用任何语言编写的Web应用程序/ API。如上所述，有许多原因导致软件在无人看管的情况下腐烂。 Mobileapps也有此功能。迁移Android，iOS或…的版本

基础架构作为代码aslo的配置/清单会遭受此困扰。 Terraform尚未发布1.x，但这些年来发生了许多变化。如果您使用的是Cloud Foundry或Kubernetes，则将经历一些变化，这意味着您需要工作。

自动执行YAML中从Kubernetes n升级到n + 1所需的更改，感觉像是一种非常有用的工具。

存在Snyk，Renovate，Dependabot等可以发出请求以更新依赖关系的事物。 Mpost语言有一个打包工具，数字的增加非常简单。这些东西往往无法管理破坏性的API更改。颠覆补丁或次要依赖关系升级是可以的，但是拥有破坏性API更改的专业人士往往需要人员参与。

为什么？我们能解决这个问题的工具吗？当发布新版本的Spring时，它是否可以包含一组伴随的转换，这些转换将使整个生态系统安全，快速地升级？

由于对编译器没有什么兴趣（并且从事过商业解释器的工作），我倾向于将代码编辑操作视为转换，而不是字符。对基于转换的编辑器进行了一些研究，但我没有看到太多其他内容。

主要版本升级可能以类似的方式表达在转换方面，也可能以类似的方式表示。因此，如果在依赖关系的主要版本之间删除了一个类，则所需的转换可能包括：

从改编的方法改编参数-曾经从ApplicationSingleton获得的Context，但现在已显式传递

然后，您需要针对这些转换集的序列化格式和发布机制。

我所看到的与此最接近的地方是Google实际上是在同一目标语言中做到这一点的。他们使用Go语言发布了一个名为fix的工具。它在1.x发行之前自动升级了现有代码，从那时起，它们就具有了Go 1兼容性文档。

我有兴趣（无论是在学术上还是在商业上）生产一种看起来相似但适用范围更广的工具。

因此，拥有一些可以采用代码/配置的东西，生成一个抽象语法树（AST），然后应用一组转换。较大的一个可能是将升级框架从n升级到n + 1，其中涉及许多较小的转换。对于每次转换，您都需要查询AST以了解oldAPI的用法，然后尝试应用将旧API映射到新API的转换。

我找到了一篇相关的论文。鉴于事情还没结束，是太难了还是行不通，还是时间错误？

因此，我认为这将是自动升级的下一个发展趋势。这似乎是一个很大的市场-有多少公司愿意为您解决这些问题并为他们解决问题，并让他们专注于业务逻辑而不是担心问题？

但是我并没有花时间去计划确认潜在市场，看看解决这个问题有多困难：）