未来验证您的应用程序有哪些选择？答案

【问题标题】：What are some options for future proofing your application?未来验证您的应用程序有哪些选择？
【发布时间】：2010-10-23 20:15:57
【问题描述】：

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

【问题讨论】：

我不知道为什么这被标记为“与编程无关”。软件设计决策显然会影响系统的使用寿命。

标签： future-proof

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

【讨论】：

我不应该写 128 位 ;) j/k

【解决方案4】：

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

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

维护人员选择放弃由于摩尔定律或可用性改进而带来的性能改进，转而支持多年来几乎不进行维护。

【讨论】：

【解决方案5】：

自动化测试也有帮助。并不是说您的应用程序会被“证明”，但我会知道当事情发生变化时必须解决什么问题。

【讨论】：

【解决方案6】：

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

year(now()) 一年
DateSubmitted BETWEEN year(now()) AND DATEADD(year,1,year(now())) 表示范围

当然，这些只是例子。

【讨论】：