長寿命（20年以上）向けのWebアプリケーションの開発
私は現在、政府の土地計画のためのWebアプリケーションを開発しています。アプリケーションは主にブラウザーで実行され、ajaxを使用してデータをロードおよび保存します。
私は最初の開発を行い、それから卒業します（それは学生の仕事です）。この後、残りのチームは必要に応じて時々機能を追加します。彼らはコーディングの方法を知っていますが、ほとんどが土地計画の専門家です。
Javascriptテクノロジが変化するペースを考えると、20年後も機能するコードをどのように書くことができますか？具体的には、コードの将来性を保証するために、どのライブラリ、テクノロジー、およびデザインアイデアを使用（または回避）する必要がありますか？
そのような寿命のためにソフトウェアを計画することは、未来がどうなるかわからないので難しいです。コンテキスト：Javaは1995年に21年前に公開されました。XmlHttpRequestは最初にInternet Explorer 5の独自の拡張機能として利用可能になりました。1999年に17年前に公開されました。それが完了するまで約5年かかりました。主要なすべてのブラウザで利用できるようになりました。これから先を見据えようとしている20年は、リッチWebアプリケーションが存在していた頃です。
それ以来、確かに同じことがいくつかあります。強力な標準化の取り組みがあり、ほとんどのブラウザーは、関係するさまざまな標準によく準拠しています。 15年前にブラウザー間で機能していたWebサイトは、各ブラウザーの回避策を使用したのではなく、すべてのブラウザーの共通サブセットを対象としたため、同じように機能します。
他のものが出入りしました–最も目立つのはFlashです。 Flashにはさまざまな問題があり、その終焉に至りました。最も重要なのは、それが単一の会社によって制御されていたことです。 Flashプラットフォーム内での競争の代わりに、FlashとHTML5の間の競争があり、HTML5が勝ちました。
この歴史から、いくつかの手がかりを集めることができます：
シンプルに保つ：回避策を使用せずに、現在機能していることを実行します。この動作は、後方互換性の理由から、将来にわたって利用可能になる可能性があります。
独自技術への依存を避け、オープンスタンダードを好む。
今日のJavaScriptの世界は、ライブラリとフレームワークの流動性が高く、比較的不安定です。ただし、20年以内に問題になるものはほとんどありません。それまでにまだ使用されると確信している唯一の「フレームワーク」はVanilla JSです。
ライブラリまたはツールを使用すると、開発が非常に簡単になるので、まず、今日サポートされている標準に基づいて構築されていることを確認してください。次に、ライブラリまたはツールをダウンロードし、ソースコードに含める必要があります。コードリポジトリには、システムを実行可能にするために必要なすべてのものが含まれている必要があります。外部のものは、将来壊れる可能性のある依存関係です。これをテストする興味深い方法は、コードをサムドライブにコピーし、別のオペレーティングシステムがインストールされた新しいコンピューターに移動し、インターネットから切断して、フロントエンドが機能するかどうかを確認することです。プロジェクトがプレーンHTML + CSS + JavaScriptとおそらくいくつかのライブラリーで構成されている限り、合格するでしょう。
コードが20年間存続することよりもさらに重要なことは、dataが20年間存続することです。おそらく、それは保存する価値があることです。データの扱いが簡単であれば、その上に新しいテクノロジーを使用して代替システムを構築するのは簡単です。
- したがって、明確で十分に文書化されたデータモデルから始めます。
- Oracleなどの確立され、サポートされているデータベースシステムを使用する[1] またはSQL Server。
- 基本的な機能を使用してください。派手な新しい機能を詰め込もうとしないでください。
- 単純よりも賢いを優先します。
- 将来の保守性はパフォーマンスなどの側面を犠牲にして得られることを受け入れます。たとえば、ストアドプロシージャを使用したくなるかもしれませんが、誰かがシステムをより単純なストレージソリューションに移行できないようにすると、将来の保守性が制限される可能性があります。
それができれば、アプリ自体の将来性を保証するのはより簡単です。これは、データモデルのラッパーであり、たとえば、10年後にJavascriptを使用しなくなった場合や、アプリをWASMまたは何か。モジュール化を維持し、相互依存性を低くすると、将来のメンテナンスが容易になります。
[1] この回答に対するほとんどのコメントは、DBにOracleを使用することに対して強いスタンスをとっています。Oracleが扱いにくい理由の多くは完全に正当な理由であり、学習曲線が急で、インストールのオーバーヘッドがあります。 OracleをDBとして選択する場合、これらは完全に有効な懸念事項ですが、私たちのケースでは、汎用DBではなく、主な懸念事項であるmaintainabilityを探しています。 Oracleは70年代後半から存在しており、今後何年にもわたってサポートされる可能性があります。また、Oracleの運用を維持するのに役立つコンサルタントとサポートオプションの巨大なエコシステムがあります。これは多くの企業にとって高額な混乱ですか？承知しました。しかしデータベースを20年間実行し続けますか？非常に可能性が高いです。
amonによる以前の回答 は素晴らしいですが、言及されていない2つの追加の点があります。
ブラウザーだけではありません。デバイスも重要です。
amonは「15年前にブラウザ間で機能していたWebサイトは今でも同じように機能する」という事実に言及している、これは本当です。ただし、15年ではなく10年前に作成されたWebサイトを見てください。作成されたWebサイトは、ほとんどのユーザーのほとんどのブラウザーで機能しました。今日、ブラウザの変更ではなく、デバイスの変更により、大部分のユーザーはこれらのWebサイトをまったく使用できなくなりました。これらのWebサイトは、モバイルデバイスの小さな画面でひどく見え、開発者がJavaScript
clickイベントに依存することを決定した場合、最終的にまったく機能しません、tapイベントも重要であることを知らずに。あなたは間違った主題に焦点を合わせています。
テクノロジーの変更は1つですが、さらに重要なのは要件の変更です。製品のスケーリングが必要な場合や、追加機能が必要な場合、または現在の機能を変更する必要がある場合があります。
ブラウザー、デバイス、W3Cなどに何が起こるかは関係ありません。
リファクタリングできるようにコードを記述した場合、製品はテクノロジーとともに進化します。
誰も理解して保守できない方法でコードを作成する場合、テクノロジーは問題ではありません。環境が変化しても、アプリケーションはダウンします。たとえば、別のオペレーティングシステムへの移行や、自然なデータの増加などの簡単なことです。 。
例として、私はソフトウェア開発に10年間携わっています。数十と数十のプロジェクトの中で、変更することにしたのは2つだけでしたテクノロジーのため、より正確にはPHP過去10年間で大幅に進化しました。サイトが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フォームではなくクライアントに配置することをお勧めします。 virtualizationのおかげで、同じアプリケーションを同じOSインスタンスで非常に長い時間実行できる可能性があります。これは実際にはいいとは限りませんが、それは、アプリが20年後も、高額なメンテナンスやハードウェアのコストなしで動作することを保証するものです。これを行うと、少なくとも古いコードを引き続き実行するという安全で安価なフォールバックが得られます。
また、私は一部のテクノロジースタックは他のものよりも安定していますを見つけました。 .NETには、現時点で可能な限りの下位互換性の話があります。マイクロソフトはそれについて真面目です。 JavaおよびC/C++も非常に安定しています。Pythonは、Python 3破壊的な変更。Webの破壊はブラウザーベンダーの選択肢ではないため、JavaScriptは実際には非常に安定しているように見えます。ただし、おそらく、実験的またはファンキーなものに依存するべきではありません。（「ファンキー」は、それ"）。
他の答えは理にかなっています。しかし、クライアントテクノロジーに関するコメントは、複雑すぎます。私は過去16年間、開発者として働いています。私の経験では、クライアントコードを直感的に保つ限り、問題はありません。したがって、フレームやiframeなどによる「ハッキング」はありません。ブラウザで明確に定義された関数のみを使用してください。
ブラウザで互換性モードを常に使用して、それらを機能させ続けることができます。
私の主張を証明するために、ほんの数か月前に、17年間Webアプリケーションを実行している顧客のJavaScriptコードのミレニアムバグを修正しました。最近のマシン、最近のデータベース、最近のオペレーティングシステムでも動作します。
結論：シンプルでクリーンな状態を維持してください。大丈夫です。