長寿命（20年以上）向けのWebアプリケーションの開発

現在、政府の土地計画用のWebアプリケーションを開発しています。アプリケーションは主にブラウザで実行され、ajaxを使用してデータをロードおよび保存します。

最初の開発をしてから卒業します（学生の仕事です）。この後、チームの残りのメンバーは、必要に応じて随時機能を追加します。彼らはコーディングの方法を知っていますが、大部分は土地計画の専門家です。

Javascriptテクノロジーが変化するペースを考えると、20年経った今でも動作するコードをどのように書くことができますか？具体的には、コードを将来に備えて使用する（または避ける）必要があるライブラリ、テクノロジ、および設計のアイデアはどれですか

そのような寿命のためにソフトウェアを計画することは困難です。なぜなら、私たちは未来がどうなるかわからないからです。ちょっとしたコンテキスト：Javaは21年前の1995年に公開されました。XmlHttpRequestは、17年前に1999年に公開されたInternet Explorer 5の独自の拡張機能として初めて利用可能になりました。すべての主要なブラウザで利用できるようになるまで、約5年かかりました。将来を見据えようとしている20年は、リッチなWebアプリケーションが存在する頃です。

それ以降、確かに同じものがいくつかあります。強力な標準化努力が行われており、ほとんどのブラウザは関連するさまざまな標準によく適合しています。15年前にブラウザー間で機能したWebサイトは、各ブラウザーの回避策を使用したためではなく、すべてのブラウザーの共通サブセットを対象としたために機能する限り、同じように機能します。

他のこともあります-最も顕著にフラッシュ。Flashにはさまざまな問題があり、その終miseに至りました。最も重要なことは、単一の会社によって管理されていたことです。Flashプラットフォーム内での競争の代わりに、FlashとHTML5の間で競争があり、HTML5が勝ちました。

この歴史から、いくつかの手がかりを集めることができます。

• シンプルに保つ：回避策を使用せずに、今すぐ動作することを実行してください。この振る舞いは、後方互換性の理由から、今後もずっと利用可能です。

• 独自技術への依存を避け、オープンスタンダードを好みます。

今日のJavaScriptの世界は、ライブラリとフレームワークの流動性が高く、比較的不安定です。ただし、20年以内にそれらのほとんどが問題になることはありません。それまでに使用されると確信している唯一の「フレームワーク」はVanilla JSです。

ライブラリやツールを使用すると、開発が大幅に容易になるため、まず、今日のよくサポートされている標準に基づいて構築されていることを確認してください。次に、ライブラリまたはツールをダウンロードして、ソースコードに含める必要があります。コードリポジトリには、システムを実行可能にするために必要なすべてが含まれている必要があります。外部のものはすべて、将来壊れる可能性のある依存関係です。これをテストする興味深い方法は、コードをサムドライブにコピーし、別のオペレーティングシステムを使用する新しいコンピューターに移動し、インターネットから切断して、フロントエンドを動作させることができるかどうかを確認することです。あなたのプロジェクトがプレーンなHTML + CSS + JavaScriptとおそらくいくつかのライブラリで構成されている限り、あなたはおそらく合格するでしょう。

コードが20年間存続することよりもさらに重要なことは、データが20年間存続することです。チャンスは、それは保存する価値があることです。データの操作が簡単な場合、新しいテクノロジーを使用してその上に代替システムを構築するのは簡単です。

• そのため、明確で十分に文書化されたデータモデルから始めます。
• Oracle ^[1]やSQL Server など、確立され、十分にサポートされているデータベースシステムを使用します。
• 基本的な機能を使用し、派手な新しい機能を絞り込もうとしないでください。
• 賢いよりもシンプルを好む。
• パフォーマンスなどの側面を犠牲にして、将来の保守性がもたらされる可能性があることを受け入れます。たとえば、ストアドプロシージャを使用したくなるかもしれませんが、誰かがシステムをよりシンプルなストレージソリューションに移行できないようにすると、将来の保守性が制限される可能性があります。

それができたら、アプリ自体の将来の保証はより簡単です。これは、データモデルのラッパーであり、たとえば10年後に誰もJavascriptを使用しなくなった場合に置き換えることができ、アプリをWASMまたは何か。物事をモジュール化し、相互依存性を低く保つことで、将来のメンテナンスが容易になります。

^[1]この回答へのほとんどのコメントは、OracleをDBに使用することに対して強いスタンスを取ります。DBとしてOracleを選択する場合、これらは完全に有効な懸念事項ですが、このケースでは、汎用DBを探しているのではなく、主な懸念事項が保守性であるものを探しています。Oracleは70年代後半から存在しており、今後何年もサポートされる予定です。また、コンサルタントとサポートオプションの巨大なエコシステムがあり、それを実行し続けるのに役立ちます。これは多くの企業にとって高額な混乱ですか？承知しました。しかし、データベースを20年間実行し続けますか？非常に可能性が高いです。

amonによる以前の答えは素晴らしいですが、言及されなかった2つの追加ポイントがあります。

• ブラウザーだけではありません。デバイスも重要です。

  amonは、「15年前にブラウザー間で機能していたWebサイトが同じように機能する」という事実に言及していますが、これは事実です。ただし、15年ではなく10年前に作成されたWebサイトを見てください。作成されたWebサイトは、ほとんどのユーザーのほとんどのブラウザーで機能していました。今日、ユーザーの大部分は、ブラウザーが変わったためではなく、デバイスが変わったため、これらのWebサイトをまったく使用できません。これらのWebサイトは、モバイルデバイスの小さな画面ではひどく見え、開発者がJavaScript clickイベントに依存することを決定した場合、そのtapイベントが重要であることを知らずに最終的にはまったく機能しません。

• あなたは間違った主題に焦点を合わせています。

  技術の変更は1つのことですが、より重要なことは要件の変更です。製品のスケーリングが必要な場合、追加機能が必要な場合、または現在の機能を変更する必要がある場合があります。

  ブラウザ、デバイス、またはW3Cなどに何が起こるかは関係ありません。

  リファクタリング可能な方法でコードを記述すると、製品はテクノロジーとともに進化します。

  誰も理解して保守できない方法でコードを作成する場合、テクノロジーは重要ではありません。環境の変化は、アプリケーションをダウンさせることになります。 。

  例として、私はソフトウェア開発に10年間携わっています。数十件のプロジェクトの中で、テクノロジーのために変更することに決めたのは2つだけでした。より正確には、過去10年間でPHPが大きく進化したためです。それは顧客の決定でさえありませんでした：サイトがPHPの名前空間またはクロージャを使用している場合、彼はそれほど気にしません。ただし、新しい要件とスケーラビリティに関連する変更には、たくさんありました！

あなたは20年間続くことを計画していません。簡潔でシンプル。代わりに、目標を区分化にシフトします。

アプリデータベースは非依存ですか？今すぐデータベースを切り替える必要がある場合は、できますか。論理言語にとらわれません。今すぐアプリをまったく新しい言語で書き直さなければならない場合は、できますか？SRPやDRYなどの優れた設計ガイドラインに従っていますか？

私は20年以上もプロジェクトを稼働してきましたが、状況が変わることを伝えることができます。ポップアップのように。20年前にはポップアップに頼ることができましたが、今日ではできません。XSSは20年前のものではありませんでしたが、今ではCORSを考慮する必要があります。

そのため、ロジックが適切に分離されていることを確認し、特定のベンダーに固定するようなテクノロジーを使用しないようにします。

これは時には非常に注意が必要です。たとえば.NETは、他のアダプターに相当するものがないMSSQLデータベースアダプターのロジックとメソッドを公開するのに優れています。MSSQLは今日では良い計画のように思えるかもしれませんが、20年間はそうでしょうか？知るか。これを回避して、データレイヤーをアプリケーションの他の部分から完全に分離する方法の例。その後、最悪の場合、データ層全体を書き直すだけで、アプリケーションの残りの部分は影響を受けません。

言い換えれば、車のように考えてください。あなたの車は20年も経たないでしょう。しかし、新しいタイヤ、新しいエンジン、新しいトランスミッション、新しい窓、新しい電子機器などにより、同じ車が非常に長い間道路を走ることができます。

@amonや他のいくつかの回答は素晴らしいですが、別の観点からこれを見ることをお勧めします。

私は20年以上も使用されてきたプログラムやコードベースに依存している大手メーカーや政府機関と仕事をしてきましたが、それらはすべて共通点が1つありました。会社がハードウェアを制御していました。実行するものを制御する場合、20年以上にわたって実行可能で拡張可能なものを用意することは難しくありません。これらのグループの従業員は、展開マシンよりも数百倍速い最新のマシンでコードを開発しました...しかし、展開マシンは時間内に凍結しました。

Webサイトでは、サーバーとブラウザーの2つの環境を計画する必要があるため、状況は複雑です。

サーバーに関しては、2つの一般的な選択肢があります。

• さまざまなサポート機能をオペレーティングシステムに依存します。サポート機能ははるかに高速ですが、OSを「凍結」する必要がある場合があります。その場合は、サーバーのOSインストールのバックアップを準備する必要があります。10年以内に何かがクラッシュした場合、OSを再インストールしたり、別の環境で動作するようにコードを書き直そうとして、誰かを夢中にさせたくありません。

• 特定の言語/フレームワーク内でバージョン管理されたライブラリを使用します。これは低速ですが、仮想環境にパッケージ化でき、異なるオペレーティングシステムまたはアーキテクチャで実行される可能性があります。

ブラウザに関しては、サーバー上ですべてをホストする必要があります（つまり、グローバルCDNを使用してファイルをホストすることはできません）。将来のブラウザはHTMLとJavascriptを（少なくとも互換性のために）引き続き実行すると想定できますが、それは実際には推測/仮定であり、それを制御することはできません。

ほとんどのアプリケーションの中核はデータです。データは永遠です。コードはより使いやすく、変更可能で、順応性があります。ただし、データは保存する必要があります。そのため、本当に堅実なデータモデルの作成に焦点を当てます。スキーマとデータをきれいに保ちます。新しいデータベースが同じデータベースの上に構築される可能性があることを予想してください。

整合性制約を実施できるデータベースを選択します。時間の経過とともに、強制されていない制約に違反する傾向があります。誰も気づかない。外部キー、一意の制約、チェック制約、検証のトリガーなどの機能を最大限に活用します。インデックス付きビューを悪用して、テーブル間の一意性制約を強制するいくつかのトリックがあります。

そのため、アプリケーションがいつか書き換えられることを受け入れる必要があるかもしれません。データベースがクリーンな場合、移行作業はほとんどありません。移行は、労力と欠陥の点で非常に高価です。

テクノロジーの観点からは、クライアント上のJavaScriptフォームではなく、ほとんどのアプリケーションをサーバー上に配置することをお勧めします。仮想化のおかげで、おそらく同じアプリケーションを同じOSインスタンスで非常に長い時間実行できるでしょう。これはあまり良いことではありませんが、高価なメンテナンスやハードウェアのコストなしで、アプリが20年後に機能することを保証します。これを行うと、少なくとも、古い作業コードを実行し続けるという安全で安価なフォールバックが得られます。

また、一部の技術スタックは他の技術スタックよりも安定していることがわかりました。.NETには、現在、可能な限り最高の下位互換性のストーリーがあります。マイクロソフトはそれについて非常に深刻です。JavaとC / C ++も非常に安定しています。Python 3の重大な変更により、Pythonは非常に不安定であることが証明されました。Webを壊すことはブラウザベンダーにとって選択肢ではないため、JavaScriptは実際には非常に安定しているように見えます。ただし、実験的またはファンキーなものに頼るべきではありません。（「ファンキー」は「見ればわかる」と定義されています）。

他の答えは理にかなっています。ただし、クライアントテクノロジーに関するコメントは、物事の複雑化を超えていると感じています。私は過去16年間、開発者として働いてきました。私の経験では、クライアントコードを直感的に保つ限り、大丈夫です。したがって、フレーム/ iframeなどを使用した「ハッキング」はありません。ブラウザでは、明確に定義された機能のみを使用してください。

ブラウザーの互換モードを常に使用して、それらを機能させ続けることができます。

私の主張を証明するために、ほんの数か月前に、私は17年間Webアプリを実行している顧客のjavascriptコードのミレニアムバグを修正しました。最近のマシン、最近のデータベース、最近のオペレーティングシステムでも動作します。

結論：シンプルでクリーンな状態に保つと、大丈夫です。

いくつかの公理：

• 真実は生き残る。このコンテキストでは、アルゴリズムとデータモデルになります。これは、問題空間の「何」と「どのように」を忠実に表します。しかし、常に改善と改善の可能性、または問題自体の進化の可能性があります。
• 言語は進化します。これは、自然言語の場合と同様にコンピューター言語の場合にも当てはまります。
• すべてのテクノロジーは陳腐化に対して脆弱です。一部のテクノロジーでは他のテクノロジーよりも時間がかかる場合があります

最も安定した技術と標準（陳腐化に対する脆弱性が最も低いもの）は、所有権がなく、最も広く採用されているものです。採用範囲が広いほど、ほとんどすべての形態の変化に対する慣性が大きくなります。独自の「標準」は、常に所有者と競争力の運命と気まぐれに対して脆弱です。

コンピューター業界では20年が非常に長い時間です。5年がより現実的な目標です。5年後には、アプリケーションが解決しようとしている問題全体が完全に再定義される可能性があります。

説明するいくつかの例：

CとC ++は長い間使用されてきました。ほぼすべてのプラットフォームに実装されています。C ++は進化し続けていますが、「ユニバーサル」機能（すべてのプラットフォームで利用可能な機能）は、非推奨になることはほとんどありません。

Flashはほぼ普遍的な標準になりましたが、独自仕様です。人気のあるモバイルプラットフォームでサポートしないという企業の決定は、基本的にどこでもそれを運命づけています。モバイルが主流となった主要な市場を見逃したくないでしょう。

WinTel（Windows / x86）は、MicrosoftおよびIntelに独占権がありますが、最適ではないプラットフォーム（16ビット内部/ 8ビット外部8088と同時期のApple Macintosh 32ビット内部/ 16ビット外部68000）で開始し、侵食しました消費者市場でのAppleにとっては、ビジネスプラットフォームにとって事実上の選択です。その間ずっと（25年）、後方互換性へのコミットメントにより、将来の開発が妨げられ、古いボックスで機能していたものが新しいボックスでも機能するというかなりの自信が生まれました。

最終的な考え

JavaScriptは、ビジネスロジックの実装に最適な選択肢ではない場合があります。データの整合性とセキュリティの理由から、ビジネスロジックはサーバーで実行する必要があります。そのため、クライアント側のJavaScriptはUIの動作に制限する必要があります。サーバー上でさえ、JavaScriptは最良の選択ではないかもしれません。小さなプロジェクトでは他のスタック（JavaまたはC＃）よりも簡単に作業できますが、事態が複雑になったときに、より適切で組織化されたソリューションを作成するのに役立つ形式性が欠けています。