有什么选择可以在将来证明您的申请？

Question

我正在考虑尽量减少未来对尚未编写的应用程序的影响。我试图避免任何第三方产品，甚至避免操作系统特定的电话。任何人都可以提出其他未来证明应用程序的方法。这个想法不需要在10年或20年内重写主要部分，并且只需要进行维护（错误修复）。

Answer 1

如果您希望程序在这段时间内继续运行（在现代操作系统上），您可能最终只能用纯ANSI C（或C ++）编写它。多年来，其他任何事情都可能需要进行一些调整 - 并且没有人真正知道在未来10到20年内会发生什么。

尽管如此，这里有一些提示可以减少这些问题：

1. 避免奇怪的依赖。如果您要依赖某些库，请确保它非常已经完善（因此可能至少在这10到20年中有5年存活下来），或者至少是开源的，所以如果需要，你可以自己分叉。
2. 避免特定于操作系统的呼叫。这将是一个平衡的行为1. - 你可以使用包装库，如boost或Qt或glib或你有什么 - 但这会增加兼容性问题的机会在那方面。
3. 记录一切。事实是，无论你怎么努力，这个程序都需要兼容性修复和错误修复，并且可能还有功能添加。因此，让15年后出现的那个糟糕的维护程序员的生活变得更轻松。 ：）

Answer 2

挖掘出仍在当今机器上运行的10年和20年历史的程序，看看它们为什么仍在运行以及为什么它们具有价值。我看到一些计算密集型的基于控制台的应用程序仍然偶尔使用，大多数是用C和FORTRAN编写的，由其他应用程序调用。如果您的应用程序有很多GUI，您确定它在几十年后仍然具有任何价值吗？也许考虑将用户界面从核心功能中分离出来，以便随着UI范例的变化和发展，将来可以替换UI。如果以非常模块化的方式编写系统，可以保留仍然提供价值的模块，而可以替换明显过时的模块。

Answer 3

以64位编写。我们现在发现许多第三方依赖项不支持64位，因此我们遇到了问题。

Answer 4

构建一个在10年内几乎不需要维护的应用程序的最佳方法是查看10年前构建并仍在运行的系统。

根据我的经验，大多数不需要重大升级的系统都是通过运行10年前部署的相同或类似硬件并使用相同的界面来实现的。

由于摩尔定律或可用性改进，维护人员选择将性能改进换掉，而多年来几乎没有维护。

Answer 5

自动化测试也可以提供帮助。 并不是说你的应用程序会被“证明”，但我会知道在事情发生变化时需要修复的内容。

Answer 6

我开发的很多应用程序都在一个循环中运行（例如：每年）。我做的最重要的事情是确保它们继续工作并不是硬编码日期或日期范围。例如：

年度
• year(now())
• DateSubmitted BETWEEN year(now()) AND DATEADD(year,1,year(now()))了解范围

当然，这只是一些例子。