25 年后运行项目的设计技巧
如果创建一个需要现在运行并且可能（也许不是）10 或 25 年后运行的应用程序（主要进行数据处理），对于此类应用程序有哪些设计技巧？
一般规则适用：依赖开源软件、经过验证的平台和故障安全数据格式。
出于可读性原因，该语言必须是高级语言（也许唯一的选择是由对原始代码知之甚少的人在 15 年内重新编写应用程序）。
我会选择 UNIX(Linux)+Python+YAML/JSON(/CSV/plaintext)，对此选择或替代工具集有什么建议吗？ Scheme/lisp 已经存在很长时间了，而且考虑到一切都是独立的，因此也很难搞砸语言基础知识。
编辑：请不要忘记有关实际设计和代码的提示，例如 2038年刊！
If creating an application (that does mostly data processing) that needs to be run now and maybe (maybe not) 10 or 25 years later, what design tips are out there for such applications?
The general rules apply: rely on open source software and proven platforms and failsafe data formats.
The language must be a high-level language for readability reasons (maybe the only option will be re-writing the application in 15 years by someone who has little knowledge of the original code).
I'd go for UNIX(Linux)+Python+YAML/JSON(/CSV/plaintext), any tips for this selection or an alternative toolset? Scheme/lisp has been around for ages and is really hard to screw up the language basics as well, given that everything would be self-contained.
EDIT: please don't forget tips about actual design and code, like 2038 year issue!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
实际上，第一条要求是“使用符合国际标准组织正式规范的流行语言”。这比你提到的任何其他事情都重要得多。 （“开源”？请...有数千个 80 年代和 90 年代的公共领域程序，今天几乎不可能运行。）
例如，如果您严格按照 C99 或 C++98 进行编码，或者C++03 甚至 C++0x 规范，10 年、20 年和 50 年后，您的平台存在一个编译器的可能性大约为 99.9999%，它可以用零处理您的代码变化。可以说，这是流行语言的正式规范中最有用的事情。
严格按照这样的规范进行编码可能并不容易，因为许多重要的程序（例如带有 GUI 的任何程序）无法 100% 可移植地编写。
但这仍然是我要开始的地方。在 100% 符合标准的代码中尽可能多地实现，然后将其余部分（如 GUI）隔离在平台相关的模块中。将后者的规模最小化，你的继任者必须完成的工作也将最小化。
免费的第 3 方工具（无论是 Boost 还是 Python）可以很好地回答某些问题，但不是这个。
Actually, the #1 requirement would be "use a popular language with an International Standards Organization formal spec". This is far more important than any of the other things you mention. ("Open Source"? Please... There are thousands of public domain programs from the 80s and 90s that it would be nigh-impossible to run today.)
For example, if you code rigidly to the C99 or C++98 or C++03 or even C++0x specification, the odds are roughly 99.9999% that a compiler will exist for your platform 10, 20, and 50 years from now that can handle your code with zero changes. This is, arguably, the most useful thing about a formal spec for a popular language.
Coding rigidly to such a spec may not be easy, since many non-trivial programs (e.g. anything with a GUI) cannot be written 100% portably.
But that is still where I would start. Implement as much as you can in 100% standard-compliant code, then isolate the rest (like the GUI) in platform-dependent modules. Minimize the size of the latter, and you will minimize the work your successors have to perform.
Free 3rd-party tools -- whether something like Boost or something like Python -- are great answers to some questions, but not this one.
考虑到您将提供记录良好的源代码，如果出现任何与您当前代码兼容的新技术，他们总是可以优化代码。否则，他们就必须自己移植它。
considering that you'll be providing a well documented source code, they could always optimize the code if any new technology comes up that's compatible with your current code. Else, they'l just have to port it themselves.
了解已部署应用程序的半衰期会很有趣。我的猜测是，10 年并不罕见，企业的核心应用程序很可能已经超过 25 年了 - 那里有大量的大型机/CICS 应用程序。
因此，我认为任何认真的开发都必须预期该应用程序将使用至少 10 年。大型企业很可能有一个“长青”政策——即将他们的应用程序迁移到更高版本的操作系统、数据库等。
实际上不可能事后猜测任何平台的寿命，所以只需选择一些被广泛采用的平台，并且在某种意义上（事实上或形式上）是一个标准。
您建议的堆栈是合理的，Java 和 Spring 或 Java EE 也不错。
我会关注应用程序的模块化和“开放性”。当我说许多应用程序已有 10 多年历史时，这并不意味着它们在那时就已经石化了。这些应用程序在内部发生变化，并与越来越多的系统集成。这些 CICS 应用程序现在生成的数据可以在移动设备上查看，这在 20 年前是闻所未闻的。
因此，请考虑应用程序的接口，选择分层和模块化的架构，以允许内部发展并适应新的集成。
It would be interesting to know the half-life of a deployed application. My guess is that 10 years is not at all unusual, and the core applications of an enterprise may well be more than 25 years old - there's a heck of a lot of Mainframe/CICS apps out there.
Hence, I'd claim that any serious development has to anticipate that the application will be used for at least 10 years. Large Enterpises may well have a policy of "Evergreening" - that is migrating their applications to later versions of Operating Systems, Databases etc.
It's effectively impossible to second-guess the longevity of any platform, so just select something that's pretty widely adopted and which is in some sense (De facto or formally) a standard.
Your suggested stack is reasonable, Java and Spring or Java EE would be good too.
I would pay attention to the modularity and "openness" of the application. When I say that many apps are more than 10 years old that doesn't mean they fossilised in that time. The apps change both internally and integrate with more and more systems. Those CICS apps now produce data being viewed on mobile devices that were unheard of 20 years ago.
So look at interfaces into your application, choose a layered and modular architecture that allows the internals to evolve and accommodates new integrations.
Java 可能是一种很好的语言来编写它。java 具有出色的向后兼容性，一个大型标准库，也具有良好的向后兼容性，并且足够流行，很可能在 25 年内出现。即使 java 失宠，也有足够多的 jvm 语言（如 scala 和 clojure），它们可能会变得足够流行，以确保 jvm 和 java 作为副产品的生存。
Python 可能不是一个好的选择，因为它们偶尔会破坏兼容性（python 3 与 python 2 不兼容）。
Java may be a good language to write it in. java has excellent backwards compatibility, a large standard library that also has good backwards compatibility, and is popular enough that it will most likely be around in 25 years. Even if java falls out of favour, there are enough jvm languages like scala and clojure that one will probably become popular enough to ensure the survival of the jvm and java as a by product.
Python may not be a good choice, as they occasionally break compatibility (python 3 is not compatible with python 2).