4

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

4

6 回答 6

6

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

也就是说，这里有一些技巧可以最大限度地减少这些问题：

  1. 避免奇怪的依赖。如果您要依赖某个库，请确保它非常完善（因此可能在这 10 到 20 年中至少存活 5 年），或者至少是开源的，以便您可以在需要时自行分叉是。
  2. 避免特定于操作系统的调用。这将是与 1 的平衡行为。 - 您可以使用诸如boost或Qt或glib或 what-have-you 之类的包装库 - 但这会增加在这方面出现兼容性问题的机会。
  3. 记录一切。事实是，无论您多么努力，该程序都需要兼容性修复和错误修复，并且可能还需要添加功能。因此，让 15 年后出现的可怜的维护程序员的生活更轻松。:)
于 2009-05-05T06:50:04.290 回答
2

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

于 2009-05-05T07:22:09.173 回答
1

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

于 2009-05-05T07:11:21.010 回答
1

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

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

由于摩尔定律或可用性改进，维护者选择放弃性能改进，转而支持多年来几乎没有维护。

于 2009-05-05T07:33:23.733 回答
0

自动化测试也可以提供帮助。并不是说您的应用程序会被“证明”，但我会知道当事情发生变化时必须修复什么。

于 2009-05-05T07:25:14.580 回答
0

我开发的许多应用程序都按周期运行（例如：每年）。我为确保他们继续工作所做的最重要的事情不是硬编码日期或日期范围。例子：

  • year(now())对于这一年
  • DateSubmitted BETWEEN year(now()) AND DATEADD(year,1,year(now()))对于一个范围

当然，这些只是例子。

于 2009-05-05T16:57:15.033 回答