我将进行初始开发，然后毕业（这是学生的工作）。此后，其余团队将根据需要添加偶尔的功能。他们知道如何编码，但他们大多是土地规划专家。具体来说，我应该使用（或避免使用）哪些库，技术和设计思想来对我的代码进行过时的验证？
#1 楼
为这样的寿命规划软件非常困难，因为我们不知道未来会怎样。有一点背景：Java于21年前于1995年发布。 XmlHttpRequest最初作为Internet Explorer 5的专有扩展而可用，发布于17年前的1999年。它花了大约5年的时间才在所有主要浏览器上可用。您试图展望的20年正好是富Web应用程序甚至已经存在的时间。一直在大力进行标准化，并且大多数浏览器都很好地符合了所涉及的各种标准。 15年前跨浏览器工作的网站仍然可以正常工作，前提是该网站可以工作，因为它的目标是所有浏览器的公共子集，而不是因为它为每个浏览器都使用了变通方法。然后就走了-最明显的是Flash。 Flash存在各种导致其消失的问题。最重要的是，它由一家公司控制。并不是Flash平台内部的竞争，而是Flash和HTML5之间的竞争-HTML5赢得了胜利。
从这段历史中，我们可以得出一些线索： />保持简单：无需使用任何变通办法即可立即执行当前操作。出于向后兼容的原因，这种行为很可能在未来很长一段时间内仍然存在。
避免依赖专有技术，而是选择开放标准。库和框架。但是，它们在20年内几乎没有关系-可以肯定的是，那时仍将使用的唯一“框架”是Vanilla JS。
如果您要使用库或工具，因为它确实使开发变得容易得多，请首先确保它基于当今得到良好支持的标准。然后，您必须下载该库或工具，并将其包含在您的源代码中。您的代码存储库应包括使系统可运行所需的一切。任何外部因素都是将来可能会中断的依赖关系。一种有趣的测试方法是将代码复制到拇指驱动器，转到具有不同操作系统的新计算机，将其与Internet断开连接，然后查看是否可以使前端工作。只要您的项目由普通的HTML + CSS + JavaScript加上也许一些库组成，您就很可能会通过。
评论
到目前为止，大规模应用程序在vanilla js中是不可维护的。 ES6已经以某种方式解决了该问题，但是有一个原因使Flow或TypeScript越来越受欢迎。
–安迪
16-10-13在12:00
@DavidPacker当然，TypeScript等很棒，并且使开发更容易。但是，一旦我介绍了构建过程，构建过程所需的所有工具就将成为依赖项：NodeJS，Gulp，NPM –谁说NPM在20年后仍会在线？我必须运行自己的注册表才能确定。这并非不可能。但是，从某种意义上说，最好放手让开发变得更容易的事情，而不是长期的。
–阿蒙
16-10-13在12:29
@DavidPacker有许多动态语言，而且令人惊讶的是，许多成功的系统都是使用Smalltalk，Ruby，Perl，Python甚至使用PHP和JS构建的。虽然静态类型的语言倾向于更易于维护，而动态语言的倾向于快速原型制作更好，但并非不可能编写可维护的JS。在没有编译器的情况下，团队中较高的技能，工艺水平以及对清晰代码组织的额外重视就变得至关重要。我个人认为类型使一切变得容易，但是它们并不是万灵丹。
–阿蒙
16-10-13在13:09
我刚刚读过“在另一台计算机上使用USB并进行测试”吗？为什么不直接启动virtualbox或仅使用隐身模式（禁用ethX）。
–Kyslik
16-10-13在15:58
我不确定20年后香草JS是否可以肯定。它的历史是艰难的和实验性的，并且在发展过程中，尽管它已经成为一种令人愉悦且有效的语言（我个人更喜欢JavaScript或TypeScript），但它的发展过程还是颇为困难。不难想象，供应商可能很想放弃其中的一部分或全部，这是否意味着开始提供一种新的替代语言-正如Google似乎对Dart提出的建议，但是似乎很多事情并没有解决。 -或弃用并消除部分JS。
– KRyan
16-10-13在17:19
#2 楼
比代码存活20年甚至更重要的是，数据存活20年。很有可能是值得保留的东西。如果您的数据易于使用，则使用较新的技术在其上构建备用系统将很容易。因此，从一个清晰且文档齐全的数据模型开始。
使用成熟的，受支持的数据库系统，例如Oracle [1]或SQL Server。
使用基本功能，不要试图挤入浮华的新功能。
简单而不是聪明。
接受将来的可维护性可能会牺牲性能等方面。例如，您可能很想使用存储过程，但是如果它们阻止某人将系统迁移到更简单的存储解决方案，那么它们可能会限制将来的可维护性。
一旦有了这些，对应用程序本身进行过时的验证就变得更加简单，因为它是数据模型的包装器，例如，如果在10年内没有人再使用Javascript，可以将其替换，并且您需要将应用程序迁移到WASM或其他方式。保持模块化，减少相互依赖性，可以使将来的维护更加容易。
[1]对该答案的大多数评论都强烈反对将Oracle用于数据库，理由是Oracle很难使用它的许多完全合理的理由，学习曲线和安装开销。在选择Oracle作为数据库时，这些都是完全有效的问题，但是在我们的案例中，我们不是在寻找通用数据库，而是主要关注可维护性的数据库。 Oracle自70年代末以来一直存在，并将在未来很多年内得到支持，并且有庞大的顾问和支持选项生态系统可以帮助您保持其运行。对于许多公司来说，这是否定价过高？当然。但是，它将使您的数据库运行20年吗？很有可能。
评论
对不起，我必须说这个。如果您使用Oracle，那么您将在“易于使用”方面打动所有人。 Oracle一点也不容易使用。 SQL Server，PostgreSQL和什至MySQL都提供了许多简单的功能，而Oracle则根本没有或过于困难。与其他Oracle数据库相比，我从来没有像其他数据库那样愚蠢的问题。即使只是设置客户，对接也是一个巨大的痛苦。甚至谷歌搜索也很难。如果您想“轻松使用”，请远离Oracle。
– jpmc26
16-10-13在22:17
+1用于保持数据尽可能简单。为此使用标准SQL使用OUTER JOIN代替oracle特定的+运算符。使用简单的表格布局。不要将表标准化为绝对最大级别。确定某些表是否可以包含冗余数据，或者您是否真的必须创建一个新表，以便每个值仅存在一次。存储过程是特定于供应商的吗？如果是，则不要使用它们。不要使用您当前选择的语言中最热门的功能：与之相比，我看到了更多的没有OOP功能的COBOL程序。那完全可以。
–some_coder
16-10-14在6:46
@ jpmc26我同意您对Oracle的看法，但是正如我所说，“易于使用”并不一定是这里的主要要求。即使使用起来很麻烦，我还是希望这里有一个坚固的平台。因为当分20年摊销时，还算不错。
– Avner Shahar-Kashtan
16-10-14在7:15
确实避免使用Oracle。如今存在的唯一一个可能在20年内看起来似乎不是错误选择的数据库是Postgresql。
–约书亚
16-10-14在18:55
我想补充一点，最好使用出色的开源DBMS，因为它们很有可能不会死。如果甲骨文在10年后不再赚钱，那么11年后它将消失。 PostreSQL似乎是最好的选择。
– Shautieh
16-10-15在6:32
#3 楼
阿蒙（Amon）先前的回答很不错，但是没有提到另外两个要点：设备也很重要。amon提到了一个事实，即“在15年前跨浏览器工作的网站仍然可以正常工作”，这是事实。但是，请查看创建于十五年前的网站，而不是创建于十年前的网站，这些网站在创建时可以在大多数浏览器中为大多数用户使用。如今，很大一部分用户根本无法使用这些网站，这不是因为浏览器发生了变化，而是因为设备发生了变化。如果开发人员决定依赖JavaScript
click事件，而又不知道tap事件也很重要，那么这些网站在移动设备的小屏幕上看起来将很糟糕，并且最终根本无法正常工作。 技术变化是一回事，但更重要的是需求的变化。产品可能需要扩展，或者可能需要其他功能，或者可能需要更改其当前功能。
浏览器，设备或W3C会发生什么都无关紧要或...无论如何。
如果您以可重构的方式编写代码，则该产品将随着技术的发展而发展。
如果您以没人能理解和维护它的方式，技术也没关系：任何环境变化都会使您的应用程序瘫痪，例如迁移到其他操作系统，甚至是简单的事情（例如自然数据增长）。
例如，我从事软件开发工作十年。在数十个项目中，由于技术的原因，我决定更改的项目只有两个，更确切地说，是因为PHP在过去十年中发展了很多。这甚至不是客户的决定：如果站点使用PHP的命名空间或闭包，他也不会在乎。但是，与新要求和可伸缩性相关的更改很多！
评论
采用不同的屏幕尺寸是一个普遍的问题。目前，移动是炒作，但如果您在具有足够分辨率的屏幕上的全屏浏览器窗口中浏览此网站，则会有很多空白（浪费）空间。改变布局以及如何最好地利用可用像素来呈现信息，这从来没有以一种聪明的方式真正发生过。移动使这一点显而易见。但是，对于当前问题，朝另一个方向思考可能更为重要。
–空
16-10-13在12:46
@null：虽然我同意您的评论，但StackExchange网站可能不是您所表达观点的最佳例证。有了要显示的数据，我相信StackExchange的设计师/开发人员在需要显示时（包括在大型显示器上）做了很大的工作。您不能将主列加宽，因为文本将变得更加难以阅读，并且您不能使用多列，因为它对于简短的问题和答案看起来不太好。
– Arseni Mourzenko
16-10-13在12:56
另一个很好的例子是菜单系统中经常使用的“悬停”事件。这些菜单中的许多菜单在触摸设备上都无法使用。
– Justas
16-10-13在15:59
您对设备的了解是110％（或更高），我可以为您提供数十年的历史。早在1980年代末，我就研究了在IBM大型机和同步3270终端上运行的CICS应用程序。 CICS区域类似于服务器端应用程序，一次将屏幕满的数据发送到同步终端，因此类似于专用设备浏览器。 CICS编程可能是80％Cobol，20％PL / 1。如今，这两种语言都已过时，并且在1990年代初期Unix工作站（Sun和Apollo）的出现几乎完全摧毁了CICS。
–约翰·福科什（John Forkosh）
16-10-17在11:06
#4 楼
您不打算持续20年。干净利落。相反，您将目标转移到了分区。您的应用数据库是否不可知？如果您现在必须切换数据库，可以吗？您的逻辑语言是否不可知。如果您现在必须用一种全新的语言重写该应用程序，可以吗？您是否遵循SRP和DRY等良好的设计准则？就像弹出窗口一样。 20年前，您可以依靠弹出窗口，而今天则不能。 XSS并不是20年前的事情，现在您必须考虑CORS。
因此，您要做的是确保逻辑完全分开，并且避免使用任何将您锁定到特定供应商的技术。
有时候这可能很棘手。例如，.NET非常适合公开其MSSQL数据库适配器的逻辑和方法，该适配器在其他适配器中没有等效项。今天，MSSQL似乎是一个不错的计划，但它将保持20年吗？谁知道。如何解决此问题以使数据层与应用程序其他部分完全分离的示例。然后，在最坏的情况下，您只需要重写整个数据层，其余的应用程序就不会受到影响。您的汽车将无法使用20年。但是，有了新轮胎，新发动机，新变速箱，新车窗，新电子设备等，同一辆车可能会在很长一段时间内行驶。
评论
“如果您现在必须切换数据库，可以吗？”如果您一次只执行一行CRUD，那几乎不可能完成。
– jpmc26
16-10-13在22:26
大量的ORM与数据库无关。我可以给我在gaurentee上进行的任何项目，都可以毫不费力地从SQLLite切换到MySql和Postgre。
–牛羚
16-10-13在23:21
当您一次只对一张记录执行简单的CRUD任务时，ORM便不再是完成这项工作的很好的工具。这就是为什么我合格。我试过了。随着查询复杂性的增加，即使是最好的ORM也不只是编写查询而变得更加麻烦，而且即使您将查询强加到其中，也可以使用特定于数据库的功能或优化很快找到自己。
– jpmc26
16-10-13在23:22
定义“复杂”。这是批量操作吗？是否包括窗口查询？子查询？ CTE？工会？复杂的分组条件？每一行都有复杂的数学运算和汇总？一个查询中有多少个联接？什么样的联接？一次处理了多少行？诚然，在单行CRUD上说任何事情（请记住，这意味着每个查询一行，而不是每个Web请求一行。）有点夸张，但是当ORM变得比其价值更大时，麻烦就更短了。您认为。使查询执行良好的步骤通常是特定于数据库的。
– jpmc26
16-10-13在23:34
“您的应用程序数据库是不可知论的吗？如果您现在必须切换数据库，可以吗？您的逻辑语言是不可知论的。如果您现在必须以全新的语言重写应用程序，可以吗？” -这是绝对可怕的建议！无论您认为编程语言或数据库最大的共同点是什么，都不要人为地束缚自己-这将迫使您不断地重新发明轮子。相反，尝试找到一种自然的方式来表达您的编程语言和所选数据库中的所需行为。
–fgp
16-10-14在13:38
#5 楼
@amon和其他一些人的回答很棒，但我想建议您从另一个角度看待这个问题。使用了20多年的基础设备，它们都有一个共同点-该公司控制着硬件。当您控制某项内容运行时，使其运行20多年并具有可扩展性并不难。这些小组的员工在比部署机器快数百倍的现代机器上开发代码...但是部署机器被冻结了。您的情况很复杂，因为网站意味着您需要计划两个环境-服务器和浏览器。谈到服务器，您有两个常规选择：
依靠各种支持功能的操作系统，运行速度可能要快得多，但这意味着操作系统可能需要“及时冻结”。如果是这种情况，您将需要为服务器准备一些操作系统安装的备份。如果10年后发生崩溃，您不想让某人发疯，尝试重新安装操作系统或重写代码以在不同的环境中工作。 ，但可以打包在虚拟环境中，并且可能在不同的操作系统或体系结构上运行。
在浏览器方面，您需要将所有内容托管在服务器上（即您不能使用全局CDN托管文件）。我们可以假设将来的浏览器仍将运行HTML和Javascript（至少出于兼容性考虑），但这实际上是一种猜测/假设，您无法控制。
评论
您还必须考虑安全性。一个有20年历史的不受支持的OS可能充满安全漏洞。我在一家公司工作，并继承了这个问题。政府机构，古老的OS（幸运的是，它们早已虚拟化了），但这是一个巨大的问题，由于必须完全重写该软件（数百个意大利面条式PHP脚本，每个脚本都有数据库调用，因此升级几乎是不可能的）硬编码，使用新驱动程序不支持/ shudder的不推荐使用的功能）。
–user203448
16-10-13在18:37
如果您采用OS路线，则充其量只能希望应用了安全补丁，并且希望将来的维护人员能够在网络层屏蔽某些东西。为了长期计划这样的工作（尤其是在没有大笔预算的情况下，因为OP是学生），您基本上需要接受您的应用程序和服务器最终将变得不安全。例如，在20年后，服务器上最终将存在针对SSL版本的已知攻击……但是，该操作系统可能在10年后与openssl版本不兼容。这全部是关于最小化折衷。
–乔纳森·瓦纳斯科
16-10-13在20:50
@FighterJet，您始终可以在受支持的OS上运行防火墙，因此除SQL注入等本应进行编码的风险外，几乎没有其他风险。
–伊恩
16-10-18在11:56
@Ian：我希望。有一个防火墙。但是我没有编写代码，而是继承了它。是的，我希望可以解决成千上万个SQL漏洞，但真正的问题是代码依赖于特定版本的PHP4（该版本已被永远弃用，并且充满安全漏洞）和特定版本的数据库驱动程序（在较新的OS上不起作用），这阻止了我们升级到较新版本的数据库……关键是，依靠相同的东西并不总是有效。只是说我很高兴我不再在那里工作了。
–user203448
16-10-18在16:43
@FighterJet这实际上是我本想谈论的一个很好的例子。您最终继承了仅在特定版本的PHP4上运行的代码以及仅在特定操作系统上运行的驱动程序...因此无法升级服务器。我不主张任何人这样做，但是确实发生了。 - 很多。 FWIW，我同意你的观点，但我希望我的回答能促进人们对这类情况的思考，而不是提出建议。
–乔纳森·瓦纳斯科
16-10-18在17:23
#6 楼
大多数应用程序的核心是数据。数据是永远的。代码更容易消耗，可变，可延展。但是，必须保留数据。因此，请专注于创建真正可靠的数据模型。保持架构和数据干净。预计可能会在同一数据库的顶部构建一个全新的应用程序。选择一个能够强制执行完整性约束的数据库。随着时间的流逝，不受约束的约束往往会被违反。没有人注意。充分利用诸如外键，唯一约束，检查约束以及可能的触发条件等功能。有一些技巧可以滥用索引视图来强制执行跨表唯一性约束。如果数据库是干净的，将几乎没有迁移工作。从人工和所造成的缺陷的角度来看，迁移非常昂贵。借助虚拟化，您可能可以在相同的OS实例中运行很长时间。这并不是很好，但是可以保证该应用程序从现在起可以运行20年，而无需任何昂贵的维护和硬件成本。这样做至少可以让您继续运行旧的，可以正常运行的代码而又安全又廉价。
此外，我发现某些技术栈比其他技术栈更稳定。我想说.NET具有目前最好的向后兼容性。微软对此非常认真。 Java和C / C ++也非常稳定。 Python已经证明，随着Python 3的重大更改，它非常不稳定。实际上，JavaScript对我来说似乎很稳定，因为对于任何浏览器供应商而言，断网都不是可行的选择。但是，您可能不应该依赖任何实验性或时髦的东西。 （“ Funky”被定义为“当我看到它时便知道”）。
评论
关于.net向后兼容性的故事-相比之下，我认为我没有看到过需要Java较旧版本的Java应用。在Java 9或更高版本中，这种情况可能会发生变化，但尚未看到这种情况的发生。
–eis
16-10-17在11:29
实际上，它具有惊人的兼容性，并且并排安装旧版本不是问题。还要注意，我估计.NET BCL比Java内置类大10到100倍。
–usr
16-10-17在12:11
向后兼容意味着不需要安装旧版本。但是我们偏离了最初的问题，这与OP无关。
–eis
16-10-17在12:23
#7 楼
其他答案确实有意义。但是，我认为对客户端技术的评论过于复杂。在过去的16年中，我一直从事开发工作。以我的经验，只要保持客户代码直观，就可以了。因此，不会出现带有框架/ iframe等的“骇客”。只能在浏览器中使用定义良好的功能。您始终可以在浏览器中使用兼容模式以使其正常工作。
为了证明我的观点，就在几个月前，我为一个已经在其Web应用程序上运行了17年的客户修复了javascript代码中的千年错误。仍然可以在最新的计算机，最新的数据库，最新的操作系统上运行。
评论
HTML规范中很好地定义了框架和iframe。是什么使它们不合适？
–•uriousdannii
16-10-14在11:55
@curiousdannii：不再使用iframe（HTML5不再支持框架），而是使用帧和iframe通过脚本等异步加载内容等。它现在可以很好地工作，但它将始终有效进行安全更改。
–乔纳森·范德文（Jonathan van de Veen）
16-10-14在12:30
#8 楼
一些公理：真理仍然存在。在这种情况下，将是算法和数据模型-真实地表示问题空间的“内容”和“方式”。虽然，总会有改进和改进的潜力，或者问题本身会不断发展。
语言会不断发展。计算机语言和自然语言都是如此。
所有技术都容易过时。某些技术可能比其他技术花费更长的时间
最稳定的技术和标准（那些最不容易过时的技术和标准）往往是非专有的并且被最广泛地采用。采用范围越广，几乎对任何形式的变革的惯性就越大。专有的“标准”总是容易受到其所有者的运气和异想天开以及竞争力的影响。
在计算机行业，二十年是很长的时间。五年是更现实的目标。在五年的时间里，您的应用程序要解决的整个问题可以完全重新定义。
几个例子说明：很久。他们几乎在每个平台上都有实现。 C ++仍在不断发展，但是“通用”功能（在所有平台上都可用）几乎可以保证永远不会被弃用。公司决定在流行的移动平台上不支持它的地方基本上注定了它-如果您是为Web创作的，则希望您的内容在所有平台上都可以使用；您不想错过主要的移动市场。
WinTel（Windows / x86）尽管是Microsoft和Intel的专有软件，但在一个不太理想的平台上开始使用（内部16位/ 8位外部8088与同时代的Apple Macintosh 32位内部/ 16位外部68000）和对于苹果公司而言，在消费者市场上仍然是商业平台的事实上选择。在过去的所有时间（25年）中，对向后兼容性的承诺阻碍了未来的发展，并激发了人们很大的信心，认为旧盒子上的内容仍将适用于新盒子。 />
JavaScript可能不是实现业务逻辑的最佳选择。出于数据完整性和安全性的原因，应在服务器上执行业务逻辑，因此客户端JavaScript应限于UI行为。即使在服务器上，JavaScript也不是最佳选择。尽管对于小型项目而言，与其他堆栈（Java或C＃）相比，它更易于使用，但它缺少形式化的功能，当情况变得更加复杂时，形式化功能可以帮助您编写更好，更有组织的解决方案。
评论
1966年末，我开始在Fortran中进行编程，因此我有足够的时间来考虑这种问题。如果您遇到甚至50％可靠的答案，请告诉我。同时，只需将几乎不可避免的过时视为“工作安全” :)软件工程无止境。只是在银行托管，因为没有人敢于更新这样的关键系统。好吧，我想Voyager中运行的程序也很重要。
@Laiv一段时间以前，我使用在Vax / VMS上运行的Swift消息处理了Bankers Trust的汇款应用程序。几年后，Swift终止了所有VMS支持（报废）。男孩，确实引起了一些问题……并向我提供了BTCo的又一份合同。就像我上面说的，“工作保障” ：）。无论如何，我的观点是，即使是关键的金融市场应用也无法幸免。
“编写下一个开发人员可以理解的代码”怎么样？如果代码过时且过时，他们将需要寻找程序员来对其进行更新，那么最好的情况是他们将了解您的代码在做什么（以及可能为什么要做出某些决定）。
只需使用普通的旧HTML，没有JS，没有插件，没有花哨的东西。如果它可以在Lynx中运行，那么这对所有时间都是有益的。