开发使用寿命长（超过20年）的Web应用程序

160

我目前正在开发用于政府土地规划的Web应用程序。该应用程序主要在浏览器中运行，使用ajax加载和保存数据。

我将进行初始开发，然后毕业（这是学生的工作）。此后，其余团队将根据需要添加偶尔的功能。他们知道如何编码，但他们大多是土地规划专家。

考虑到Javascript技术的变化步伐，我如何编写从现在起20年后仍然可以使用的代码？具体来说，我应该使用（或避免使用）哪些库，技术和设计思想来对我的代码进行过时的验证？

javascript web-development future-proof

— 担
source

94

我于1966年末开始在Fortran中进行编程，所以我有足够的时间来考虑这种问题。如果您遇到甚至50％可靠的答案，请告诉我。同时，只需将几乎不可避免的过时视为“工作安全” :)

— 约翰·佛科什

11

软件工程无止境。只是在银行托管，并且因为没人敢更新这样的关键系统。好吧，我想Voyager中运行的程序也很重要。

— Laiv

9

@Laiv一段时间以前，我使用在Vax / VMS上运行的Swift消息处理了Bankers Trust的汇款应用程序。几年后，Swift终止了所有VMS支持（报废）。男孩，确实引起了一些问题……并向我提供了BTCo的又一份合同。就像我在上面说的“工作保障” ：）。无论如何，我的观点是，即使是关键的金融市场应用也无法幸免。

— John Forkosh

102

“编写下一个开发人员可以理解的代码”怎么样？如果代码过时且过时，他们将需要寻找程序员来对其进行更新，那么最好的情况是他们将了解您的代码在做什么（以及可能为什么要做出某些决定）。

— David Starkey

38

只需使用普通的旧HTML，没有JS，没有插件，没有花哨的东西。如果它可以在Lynx中运行，那么这对所有时间都是有益的。

— Gaius

132

为这样的寿命规划软件是困难的，因为我们不知道未来会怎样。有一点背景：Java于21年前于1995年发布。XmlHttpRequest最初作为Internet Explorer 5的专有扩展而可用，发布于17年前的1999年。它花了大约5年的时间才在所有主要浏览器上可用。您要展望的20年就是富Web应用程序甚至已经存在的时间。

从那以后，某些事情肯定保持不变。一直在大力进行标准化，并且大多数浏览器都很好地符合所涉及的各种标准。15年前跨浏览器工作的网站仍然可以正常工作，前提是该网站可以工作是因为它针对所有浏览器的公共子集，而不是因为它为每个浏览器都使用了变通方法。

其他事物来去去去-最显着的是Flash。Flash存在各种导致其消失的问题。最重要的是，它由一家公司控制。Flash和HTML5之间没有竞争，而没有Flash平台内部的竞争，因此HTML5赢得了胜利。

从这段历史中，我们可以得出一些线索：

保持简单：无需使用任何变通办法即可立即进行操作。由于向后兼容的原因，这种行为很可能在将来很长一段时间内仍然可用。
避免依赖专有技术，而选择开放标准。

当今的JavaScript世界相对不稳定，具有大量的库和框架。但是，它们在20年内几乎没有关系-可以肯定的是，那时唯一仍将使用的“框架”是Vanilla JS。

如果要使用某个库或工具，因为它确实使开发变得容易得多，请首先确保它基于当今得到良好支持的标准。然后，您必须下载该库或工具，并将其包含在您的源代码中。您的代码存储库应包括使系统可运行所需的一切。任何外部的依赖都可能会在将来中断。一种有趣的测试方法是将代码复制到拇指驱动器，转到具有不同操作系统的新计算机，将其与Internet断开连接，然后查看是否可以使前端工作。只要您的项目由普通的HTML + CSS + JavaScript加上也许一些库组成，您就很可能会通过。

— 阿蒙
source

4

到目前为止，大规模应用程序在vanilla js中是无法维护的。ES6已经以某种方式解决了该问题，但是有一个原因使Flow或TypeScript越来越受欢迎。

— 安迪

34

@DavidPacker当然，TypeScript等很棒，并且使开发更容易。但是，一旦我介绍了构建过程，构建过程所需的所有工具就将成为依赖项：NodeJS，Gulp，NPM –谁说NPM在20年后仍会在线？我必须运行自己的注册表才能确定。这并非不可能。但是，从某种意义上说，最好放手让开发变得更容易的事情，而不是从长远来看。

— 阿蒙

30

@DavidPacker有许多动态语言，而且令人惊讶的是，许多成功的系统已经使用Smalltalk，Ruby，Perl，Python甚至使用PHP和JS构建。尽管静态类型的语言倾向于更易于维护，而动态语言的分支倾向于快速原型制作，但编写可维护的JS并非没有可能。在没有编译器的情况下，团队中较高的技能，工艺水平以及对清晰代码组织的额外重视变得更加关键。我个人认为类型使一切变得容易，但是它们并不是万灵丹。

— 阿蒙

4

我刚刚读过“在另一台计算机上使用USB并进行测试”吗？为什么不直接启动virtualbox或仅使用隐身模式（禁用ethX）。

— Kyslik

5

我不确定，从现在开始20年后，香草JS 肯定会成为现实。它的历史是艰难的和实验性的，并且在发展过程中，尽管它已经成为一种令人愉悦和有效的语言（我个人更喜欢JavaScript或TypeScript），但它的发展过程还是颇受关注。不难想象，供应商很可能希望放弃其中的一部分或全部，这是否意味着开始提供一种新的替代语言-正如Google似乎对Dart提出的建议，但是似乎很多事情并没有解决。 -或弃用并消除部分JS。

— 瑞安（KRyan）

178

比代码存活20年甚至更重要的是，数据存活20年。很有可能是值得保留的东西。如果您的数据易于使用，则使用较新技术在其之上构建备用系统将很容易。

因此，从一个清晰且记录良好的数据模型开始。
使用已建立且受良好支持的数据库系统，例如Oracle ^[1]或SQL Server。
使用基本功能，不要试图挤入浮华的新功能。
身高简单了聪明。
接受未来的可维护性可能会牺牲性能等方面。例如，您可能很想使用存储过程，但是如果它们阻止某人将系统迁移到更简单的存储解决方案，那么它们可能会限制将来的可维护性。

一旦有了这些，就可以简化应用程序的前瞻性，因为它是数据模型的包装器，例如，如果在十年内没有人使用Javascript，并且您需要将应用程序迁移到该模型，则可以替换该应用程序。 WASM之类的。保持模块化，减少相互依赖性，可以使将来的维护更加容易。

^[1]对该答案的大多数评论都强烈反对将Oracle用于数据库，因为有很多完全合理的理由使Oracle难以使用，学习曲线和安装开销也很大。在选择Oracle作为数据库时，这些都是完全有效的关注点，但是在我们的案例中，我们并不是在寻找通用的DB，而是主要关注可维护性的对象。Oracle自70年代末以来一直存在，并将在未来很多年内得到支持，并且有庞大的顾问和支持选项生态系统可以帮助您保持运行。对于许多公司来说，这是否定价过高？当然。但是它将使您的数据库运行20年吗？很有可能。

— 阿夫纳·沙哈尔·卡斯坦（Avner Shahar-Kashtan）
source

141

对不起，我必须说这个。如果您使用Oracle，那么您将在“易于使用”方面打动所有人。Oracle一点也不容易使用。SQL Server，PostgreSQL和什至MySQL都提供了许多简单的功能，而Oracle则根本没有或过于困难。与其他Oracle数据库相比，我从来没有像其他数据库那样愚蠢的问题。即使只是设置客户，对接也是一个巨大的痛苦。甚至谷歌搜索也很难。如果您想“轻松使用”，请远离Oracle。

— jpmc26'2013-10-13

4

+1用于保持数据尽可能简单。为此，请使用标准SQL，例如，使用OUTER JOIN代替oracle特定的+运算符。使用简单的表格布局。不要将表标准化为绝对最大值。确定某些表是否可以包含冗余数据，或者您是否真的必须创建一个新表，以便每个值仅存在一次。存储过程是特定于供应商的吗？如果是，则不要使用它们。不要使用您当前选择的语言中最热门的功能：与之相比，我看到了更多的没有OOP功能的 COBOL程序。那完全可以。

— some_coder

3

@ jpmc26我同意您对Oracle的看法，但是正如我所说，“易于使用”不一定是这里的主要要求。即使使用起来很痛苦，我还是希望这里有一个坚固的平台。因为当摊销20年时，还算不错。

— Avner Shahar-Kashtan

8

确实避免使用Oracle。如今存在的唯一一个可能在20年内看起来似乎不是错误选择的数据库是Postgresql。

— 约书亚

3

我想补充一点，最好使用出色的开源DBMS，因为它们很有可能不会死。如果甲骨文在10年后不再赚钱，那么11年后它将消失。PostreSQL似乎是最好的选择。

— Shautieh

36

阿蒙（Amon）先前的回答很棒，但是有两点没有提到：

不仅仅是浏览器；设备也很重要。

阿蒙（Amon）提到了一个事实，即“一个在15年前跨浏览器工作的网站仍然可以正常工作”，这是事实。但是，请看看创建于十五年前的网站，而不是创建于十年前的网站，这些网站在创建时可以在大多数浏览器中为大多数用户使用。如今，很大一部分用户将根本无法使用这些网站，这不是因为浏览器发生了变化，而是因为设备可以使用。这些网站在移动设备的小屏幕上看起来会很糟糕，如果开发人员决定依赖JavaScript click事件，而又不知道tap事件也很重要的话，这些网站最终将根本无法工作。
您正在关注错误的主题。

技术变更是一回事，但更重要的是需求变更。产品可能需要缩放，或者可能需要具有其他功能，或者可能需要更改其当前功能。

无关紧要的是浏览器，设备，W3C或...。

如果您以可以重构的方式编写代码，那么该产品将随着技术的发展而发展。

如果您以没人能理解和维护的方式编写代码，那么技术就无关紧要：任何环境变化都会使您的应用程序瘫痪，例如迁移到其他操作系统，甚至简单的事情就是自然数据增长。

例如，我从事软件开发工作已有十年。在数十个项目中，由于技术的缘故，我决定更改的项目只有两个，更确切地说，是因为PHP在过去十年中发展了很多。这甚至不是客户的决定：如果站点使用PHP的命名空间或闭包，他也不会在乎。但是，与新要求和可伸缩性相关的更改很多！

— 阿森尼·莫尔琴科（Arseni Mourzenko）
source

4

采用不同的屏幕尺寸是一个普遍的问题。目前，移动是炒作，但如果您在具有足够分辨率的屏幕上的全屏浏览器窗口中浏览此网站，则会有很多空白（浪费）空间。改变布局以及如何最好地利用可用像素来呈现信息，从来没有真正聪明地发生过。移动使这一点显而易见。但是，对于当前问题，朝另一个方向思考可能更为重要。

— 空值

9

@null：虽然我同意您的评论，但StackExchange网站可能不是您所表达观点的最佳例证。有了要显示的数据，我相信StackExchange的设计师/开发人员在需要显示时（包括在大型显示器上）做了很大的工作。您不能将主列加宽，因为文本将变得更加难以阅读，并且您不能使用多列，因为它对于简短的问题和答案看起来不太好。

— 阿森尼·穆尔坚科

另一个很好的例子是菜单系统中经常使用的“悬停”事件。这些菜单中的许多菜单在触摸设备上都失败了。

— Justas

您对设备的了解是110％（或更高），我可以为您提供数十年的历史。早在1980年代末，我就研究了在IBM大型机和同步3270终端上运行的CICS应用程序。CICS区域类似于服务器端应用程序，一次将整个屏幕的数据发送到同步终端，因此类似于专用设备浏览器。CICS编程可能是80％Cobol，20％PL / 1。如今，这两种语言都已过时，并且在1990年代初期Unix工作站（Sun和Apollo）的出现几乎完全

— 摧毁了

31

您不打算持续20年。干净利落。相反，您将目标转移到了分区。

您的应用数据库是否不可知？如果您现在必须切换数据库，可以吗？您的逻辑语言是否不可知。如果您现在必须用全新的语言重写应用程序，可以吗？您是否遵循良好的设计准则，例如SRP和DRY？

我的项目的寿命超过20年，我可以告诉你情况发生了变化。就像弹出窗口一样。20年前，您可以依靠弹出窗口，而今天则不能。XSS并不是20年前的事情，现在您必须考虑CORS。

因此，您要做的是确保逻辑完全分开，并且避免使用任何将您锁定到特定供应商的技术。

有时这可能非常棘手。例如，.NET非常适合公开其MSSQL数据库适配器的逻辑和方法，该适配器在其他适配器中没有等效项。今天，MSSQL似乎是一个不错的计划，但它会保持20年吗？谁知道。如何解决此问题以使数据层与应用程序其他部分完全分离的示例。然后，在最坏的情况下，您只需要重写整个数据层，其余的应用程序就不会受到影响。

换句话说，将其视为汽车。您的汽车将无法使用20年。但是，有了新轮胎，新发动机，新变速箱，新车窗，新电子设备等，同一辆车可能会行驶很长一段时间。

— te
source

2

“如果您现在必须切换数据库，可以吗？”如果您一次只执行一行CRUD，那几乎不可能完成。

— jpmc26'2013-10-13

1

大量的ORM与数据库无关。我可以给我正在从事gaurentee的任何项目提供一个我可以毫不费力地从SQLLite切换到MySql和Postgre的项目。

— coteyr

5

当您一次只对一张记录执行简单的CRUD任务时，ORM便不再是非常好的工具。这就是为什么我合格。我试过了。随着查询复杂度的增加，即使是最好的ORM也不只是编写查询而变得更加麻烦，而且即使您将查询强加到其中，也可以使用数据库特定的功能或优化很快找到自己。

— jpmc26'2013-10-13

1

定义“复杂”。这是批量操作吗？是否包括窗口查询？子查询？CTE？工会？复杂的分组条件？每一行都有复杂的数学运算和汇总？一个查询中有多少个联接？什么样的联接？一次处理了多少行？诚然，在单行CRUD上说任何事情（请记住，这意味着每个查询一行，而不是每个Web请求一行。）有点夸张，但是当ORM变得比其价值更大时，麻烦更短了。您认为。使查询执行良好的步骤通常是特定于数据库的。

— jpmc26，2013年

4

“您的应用程序数据库是不可知论的吗？如果您现在必须切换数据库，可以吗？您的逻辑语言是不可知论的。如果您现在必须以全新的语言重写应用程序，可以吗？” -这是绝对可怕的建议！无论您认为编程语言或数据库最大的共同点是什么，都不要人为地束缚自己-这将迫使您不断地重新发明轮子。而是尝试寻找一种自然的方式来表达您的编程语言和所选数据库中的所需行为。

— fgp

12

@amon和其他一些人的答案很棒，但我想建议您从另一个角度看待这个问题。

我曾与大型制造商和政府机构合作，他们依赖已经使用了20多年的程序或代码库，而且它们都有一个共同点-公司控制硬件。当您控制某项内容运行时，使其具有20多年的可扩展性并不难。这些小组的员工在现代化的机器上开发了比部署机器快数百倍的代码...但是部署机器被及时冻结了。

您的情况很复杂，因为网站意味着您需要规划两种环境-服务器和浏览器。

对于服务器，您有两种常规选择：

依靠操作系统来获得各种支持功能可能要快得多，但是这意味着可能需要“及时冻结”操作系统。如果是这种情况，您将需要为服务器准备一些操作系统安装的备份。如果10年后发生崩溃，您不想让某人疯狂尝试重新安装OS或重写代码以在其他环境中工作。
在给定的语言/框架内使用版本控制的库，虽然速度较慢，但可以打包在虚拟环境中，并且可能在不同的操作系统或体系结构上运行。

对于浏览器，您需要将所有内容托管在服务器上（即，您不能使用全局CDN托管文件）。我们可以假设未来的浏览器仍将运行HTML和Javascript（至少出于兼容性考虑），但这实际上是猜测/假设，您无法控制。

— 乔纳森·瓦纳斯科
source

11

您还必须考虑安全性。一个有20年历史的不受支持的操作系统可能充满安全漏洞。我在一家公司工作，并继承了这个问题。政府机构，古老的OS（幸运的是，它们早已虚拟化了），但这是一个巨大的问题，由于必须完全重写该软件（数百个意大利面条式PHP脚本，每个脚本都有数据库调用），因此升级几乎是不可能的。硬编码，使用新驱动程序不支持/ shudder的不推荐使用的功能）。

如果您采用OS路线，充其量只能希望应用了安全补丁，并且将来的维护人员将能够在网络层屏蔽某些东西。为了长期计划这样的工作（尤其是在没有大量预算的情况下，因为OP是学生），您基本上需要接受您的应用程序和服务器最终会变得不安全。例如，在20年后，服务器上最终将存在针对SSL版本的已知攻击……但该操作系统可能在10年后与openssl版本不兼容。这全部是关于最小化折衷。

— 乔纳森·瓦纳斯科

@FighterJet，您始终可以在受支持的OS上运行防火墙，因此除了SQL注入等风险外，您几乎没有其他应为之编写的风险。

— 伊恩

@Ian：我希望。有防火墙。但是我没有编写代码，而是继承了它。是的，我希望可以解决成千上万个SQL漏洞，但真正的问题是代码依赖于特定版本的PHP4（该版本已被永远弃用，并且充满安全漏洞）和特定版本的数据库驱动程序（在较新的OS上不起作用），这阻止了我们升级到较新版本的数据库……关键是，依靠相同的东西并不总是有效。只是说我很高兴我不再在那里工作了。

1

@FighterJet这实际上是我本想谈论的一个很好的例子。您最终继承了仅在特定版本的PHP4上运行的代码以及仅在特定操作系统上运行的驱动程序...因此无法升级服务器。我不主张任何人这样做，但是确实发生了。 - 很多。FWIW，我同意你的观点，但我希望我的回答能促进人们对这类情况的思考，而不是提出建议。

— 乔纳森·瓦纳斯科

6

大多数应用程序的核心是数据。数据是永远的。代码更易消耗，可变，可扩展。但是，必须保留数据。因此，请专注于创建真正可靠的数据模型。保持架构和数据干净。预计可能会在同一数据库的顶部构建一个新的应用程序。

选择一个能够强制执行完整性约束的数据库。随着时间的流逝，不受约束的约束往往会被违反。没有人注意。充分利用诸如外键，唯一约束，检查约束以及可能的触发条件等功能。有一些技巧可以滥用索引视图来强制执行跨表唯一性约束。

因此，也许您需要接受该应用程序将在某个时间被重写。如果数据库是干净的，将几乎没有迁移工作。就劳动力和所造成的缺陷而言，迁移非常昂贵。

从技术角度来看，将大多数应用程序放置在服务器上而不是JavaScript形式放在客户端上可能是一个好主意。借助虚拟化，您可能可以在相同的OS实例中运行很长时间。这并不是很好，但这是保证该应用程序从现在起20年后可以正常工作，而无需任何昂贵的维护和硬件成本。这样做至少可以让您继续运行旧的，有效的代码而又安全又便宜。

此外，我发现某些技术栈比其他技术栈更稳定。我想说.NET具有目前最好的向后兼容性故事。微软对此非常认真。Java和C / C ++也非常稳定。Python已经证明，随着Python 3的重大更改，它非常不稳定。实际上，JavaScript对我来说似乎非常稳定，因为对于任何浏览器供应商而言，断网都不是可行的选择。但是，您可能不应该依赖任何实验性的或时髦的东西。（“ Funky”被定义为“当我看到它时就知道”）。

— usr
source

关于.net向后兼容性的故事 -相比之下，我认为我没有见过需要Java较旧版本的Java应用。在Java 9或更高版本中，这种情况可能会发生变化，但是尚未看到这种情况的发生。

— eis

实际上，它具有惊人的兼容性，并且并排安装旧版本不是问题。还要注意，我估计.NET BCL比Java内置类大10到100倍。

— usr

向后兼容意味着无需安装旧版本。但是我们偏离了最初的问题，这与OP并没有真正的关系。

— eis

0

其他答案确实有意义。但是，我认为对客户端技术的评论过于复杂。在过去的16年中，我一直从事开发工作。以我的经验，只要保持客户代码直观，就可以了。因此，不会出现带有框架/ iframe等的“骇客”。仅在浏览器中使用定义明确的功能。

您始终可以在浏览器中使用兼容模式来保持它们的正常运行。

为了证明我的观点，就在几个月前，我为一个已经运行其Web应用程序17年的客户修复了javascript代码中的一个千年错误。仍然可以在最新的机器，最新的数据库，最新的操作系统上使用。

结论：保持简单和清洁，应该没问题。

— 乔纳森·范德文
source

1

HTML规范中很好地定义了框架和iframe。是什么使它们不合适？

— curiousdannii

3

@curiousdannii：不再使用iframe（HTML5不再支持框架），而是使用帧和iframe通过脚本等方式异步加载内容。进行安全更改。

— 乔纳森·范德文（Jonathan van de Veen）

-2

一些公理：

真理永存。在这种情况下，将是算法和数据模型-真实地表示问题空间的“内容”和“方式”。虽然，始终存在改进和改进的潜力，或者问题本身的发展。
语言不断发展。计算机语言和自然语言都是如此。
所有技术都容易过时。某些技术可能需要更长的时间

最稳定的技术和标准（那些最不容易过时的技术和标准）往往是非专有的并且被最广泛地采用。采用范围越广，几乎对任何形式的变革的惯性就越大。专有的“标准”总是容易受到其所有者和竞争力量的命运和幻想的影响。

在计算机行业，二十年是很长的时间。五年是一个更现实的目标。在五年的时间内，您的应用程序要解决的整个问题可以完全重新定义。

一些例子说明：

C和C ++已经存在很长时间了。他们几乎在每个平台上都有实现。C ++仍在不断发展，但是“通用”功能（在所有平台上都可用）几乎可以保证永远不会被弃用。

Flash几乎成为通用标准，但它是专有的。公司决定在流行的移动平台上不支持它的地方基本上注定了它-如果您是为Web创作的，则希望您的内容在所有平台上都可以使用；您不想错过主要的移动市场。

WinTel（Windows / x86）尽管是Microsoft和Intel的专有软件，但在一个不太理想的平台上开始使用（内部16位/ 8位外部8088与同时代的Apple Macintosh 32位内部/ 16位外部68000）和侵蚀对于苹果公司而言，在消费者市场上仍然是商务平台的事实上选择。在过去的所有时间（25年）中，对向后兼容性的承诺阻碍了未来的发展，并激发了人们很大的信心，认为旧机器上的内容仍然可以在新机器上使用。

最后的想法

JavaScript可能不是实现业务逻辑的最佳选择。出于数据完整性和安全性的原因，应在服务器上执行业务逻辑，因此客户端JavaScript应限于UI行为。即使在服务器上，JavaScript也不是最佳选择。尽管对于小型项目而言，与其他堆栈（Java或C＃）相比，它更易于使用，但它缺少形式化的功能，当情况变得更复杂时，形式化功能可以帮助您编写更好，更组织化的解决方案。

— Zenilogix
source