有哪些选项可以让您的应用程序面向未来进行验证？
我正在考虑尽量减少对尚未编写的应用程序的未来影响。 我试图避免任何第三方产品，甚至避免操作系统特定的调用。 任何人都可以建议其他方法来证明应用程序的未来。 这个想法是在 10 或 20 年内不必重写主要部分，并且只需要进行维护（错误修复）。
I am looking at minimizing the future impact on a yet to be written application. I am trying to avoid any 3rd party products, and even avoid operating system specific calls. Can anybody suggest other ways of future proofing the application. The idea would be not having to rewrite major portions in 10 or 20 years, and that only maintenance (bug fixes) would ever need to be done.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果您希望您的程序在该时间段内继续运行（在现代操作系统上），您可能最终不得不仅使用纯 ANSI C（或 C++）编写它。 其他任何事情都可能需要多年来进行某种调整 - 没有人真正知道未来 10-20 年会发生什么。
也就是说，这里有一些技巧可以最大限度地减少此类问题：
If you want your program to keep running (on modern OSes) for that kind of time period, you'll probably end up having to write it in only pure ANSI C (or C++). Anything else is likely to need some kind of tweaking over the years - and nobody really knows what'll happen over the next 10-20 years.
That said, here are a few tips to minimize these kinds of problems:
挖掘出一些仍然在今天的机器上运行的 10 和 20 年前的程序，看看它们为什么仍然运行以及为什么它们有价值。 我看到许多基于控制台的计算密集型应用程序仍在偶尔使用，大部分是用 C 和 FORTRAN 编写的，由其他应用程序调用。 如果您的应用程序有很多 GUI，您确定它在几十年后仍然具有任何价值吗？ 也许可以考虑将用户界面与核心功能分开，这样随着 UI 范例的变化和发展，UI 可以在未来被替换。 如果您以非常模块化的方式编写系统，则可以保留仍然提供价值的模块，而可以替换那些明显过时的模块。
Dig out some 10 and 20 year old programs that still run on todays machines and see why they still run and why they are of value. I see a number of computation intensive console based apps still in occasional use, mostly written in C and FORTRAN, called by other apps. If your app has a lot of GUI, are you sure it will still have any value in a few decades time? Perhaps consider seperating the user interface from the core functionality, in such a way that the UI can be replaced in the future as UI paradigms change and evolve. If you write your system in a very modular fashion, modules that still provide value can be kept while those that are clearly obsolete can be replaced.
编写时请考虑 64 位。 我们现在发现许多第三方依赖项不支持 64 位，因此我们遇到了问题。
Write with 64-bit in mind. We're discovering now that many of our third-party dependencies don't support 64-bit, and so we have issues.
构建 10 年内仍然运行且几乎不需要维护的应用程序的最佳方法是查看 10 年前构建并仍在运行的系统。
根据我的经验，大多数不需要重大升级的系统都是通过在 10 年前部署的相同或相似硬件上运行并使用相同的接口来实现的。
维护人员选择放弃摩尔定律带来的性能改进或可用性改进，转而选择多年来几乎不需要维护。
The best way to build an application that is still functioning with little-to-no maintenance in 10 years is to look at the systems that were built and are still running from 10 years ago.
From my experience, most of those systems, which did not need major upgrades are doing so by running on the same or similar hardware that they were deployed to 10 years ago and use the same interface.
The maintainers chose to trade away the performance improvements due to Moore's law or usability improvements in favor of little to no maintenance over the years.
自动化测试也可以提供帮助。
并不是说您的应用程序将得到“验证”，但我会让您知道当情况发生变化时必须修复哪些内容。
Automate Testing can also help.
Not that your application will be "proofed", but I you'll have some idea of what has to be fixed when things changed.
我开发的许多应用程序都按周期运行（例如：每年）。 为了确保它们继续工作，我所做的最重要的事情不是硬编码日期或日期范围。 示例：
year(now())表示年份DateSubscribed BETWEENyear(now()) AND DATEADD(year,1,year(now()))表示某个范围当然，这些只是例子。
A lot of the applications I develop run on a cycle (example: yearly). The most important thing I do to ensure they continue to work is not hard-coding dates or date ranges. Example:
year(now())for the yearDateSubmitted BETWEEN year(now()) AND DATEADD(year,1,year(now()))for a rangeOf course, these are just examples.