寿命が40年以上のWebアプリケーションの設計に関するアドバイス

シナリオ

現在、私はヘルスケアプロジェクトの一員であり、その主な要件は、ヘルスケアプロバイダーがユーザーが作成したフォームを使用して、未知の属性を持つデータをキャプチャすることです。2番目の要件は、データの整合性が重要であり、アプリケーションが40年以上使用されることです。現在、過去40年間のクライアントのデータをさまざまなソース（紙、Excel、Accessなど）からデータベースに移行しています。将来の要件は次のとおりです。

• フォームのワークフロー管理
• フォームのスケジュール管理
• セキュリティ/ロールベースの管理
• 報告エンジン
• モバイル/タブレットのサポート

状況

わずか6か月で、現在の（契約している）アーキテクト/シニアプログラマーが「高速」アプローチを採用し、貧弱なシステムを設計しました。データベースは正規化されず、コードは結合され、層には専用の目的がなく、データベースで「削除」を実行するようにいくつかのBeanを設計したため、データが失われ始めています。コードベースは非常に肥大化しており、データベースが正規化されていないため、データを同期するだけのジョブがあります。彼のアプローチは、欠落したデータを復元するためにバックアップジョブに依存することであり、リファクタリングを信じていないようです。

私の調査結果をPMに提出したので、建築家は契約が終了すると削除されます。このアプリケーションを再設計するタスクが与えられました。私のチームは私と1人のジュニアプログラマで構成されています。他のリソースはありません。このシステムの再構築に集中できる6か月の要件凍結が認められました。

DrupalのようなCMSシステムを使用することをお勧めしましたが、クライアントの組織のポリシー上の理由により、システムをゼロから構築する必要があります。

寿命が40を超えるシステムを設計するのはこれが初めてです。私は3〜5年の寿命を持つプロジェクトにしか取り組んでいません。そのため、この状況は非常に新しいものですが、刺激的です。

ご質問

• どのような設計上の考慮事項が、システムをより「将来性のある」ものにしますか？
• システムをより「将来の証拠」にするために、クライアント/ PMにどのような質問をする必要がありますか？

データは王様です

2013年頃のWebアプリケーションが2053年にまだ稼働していることを期待するのは少し不合理だと思います。テクノロジーは変化するでしょう。プラットフォームは行き来します。HTMLは、それまでには古風な記憶になるかもしれません。ただし、データは引き続き存在します。

したがって、データが主な焦点です。あなたのデータがまだそこにある限り、人々はどんな新しい技術が生まれても適応することができます。データスキームが十分に検討され、拡張に適していることを確認してください。それらを指定するのに時間をかけてください。

実際のアプリケーションに関しては、おそらく「スクラッチからビルド」ディレクティブを持っているという点であなたの会社は正しいでしょう。私は10歳以上のウェブアプリを2、3維持していますが、2003年の一般的なCMSシステムに縛られていないことを非常にうれしく思います。このようなものについては、プロジェクトのニーズに合わせて特別に作成する非常に基本的なフレームワークを使用した方が良いと思います。

しかし、現実には、40年以上にわたって、同社は（できれば）進化するプラットフォームに適応するためにかなりの数のフロントエンドサービスとバックエンドサービスを作成します。そのため、個々のユーザー向けアプリケーションの寿命を5〜10年にすることを目標としています。

20年以上にわたって顧客に支払いをすることで使用されてきたソフトウェアを製造しています。コードベースは、数世代にわたるソース管理ツールよりも長持ちしています。私たちのソフトウェアは、タブレット以外のすべての弾丸を打つ。

懸念事項の一部には、ESIGNとUETAが含まれます。私たちの弁護士は、電子記録を最低10年間は​​読みやすくする必要があると考えています。完全に保持されているドキュメントについては、PDF / Aを調べる必要があります。

データベースについては、正規化についてあまり心配しないでください。代わりに、すべてをログに記録し、データの変更/削除を追跡する監査テーブルを作成することを考慮する必要があります。バージョンをアップグレードするときは、新しいバージョンを十分な時間並行してテストして、データが確実に移行されるようにしてください。この新しいバージョンのテストには、新しいオペレーティングシステムも含まれます。ここ数年、非常に不快な驚きがありました。ロールバックが必要な場合に備えて、インストールメディアとライセンスキーを保存します。バックアップをテストします。データベースに保存するオブジェクトをシリアル化する場合は、開発フレームワークが提供するシリアル化ではなく、XMLとしてシリアル化してください。

スタッフの配置には、長期的なコードベースに長期的なメモリが必要です。理想的には、あなたが周りに長い間いらっしゃった人が欲しいでしょう。それが制度的に不可能な場合は、Wikiのようなものですべてを文書化する必要があります。そして、私のアドバイスは、あなたのバグ追跡システムと連携できるウィキです。

コードベースについては、コードにコメントがあることを確認してください。あるバージョン管理システムから別のバージョン管理システムに移行すると、ほとんどの場合、チェックインコメントが失われます。私は、仕様とバグ番号に基づいて単体テストに名前を付けるのが好きです。こうすることで、単体テストがTest_Bug_1235 失敗した場合、何をどこでテストするのかを追跡できます。テストに名前を付けるほど「セクシー」というわけではありませんCheck_File_Save_Networked_Drivesが、そのようなテストは仕様とは異なり、仕様、要件、またはバグを追跡するのは困難Test_requirement_54321_case_2です。

このアプリケーションが今から20年後にどのように動作するのかを理解しようとするのではなく、元のアーキテクトが引き起こした問題を修正するために6か月を費やすべきだと思います。そこから前進します。

データベースの部分的な非正規化は、医療環境では必ずしも完全に予期しないものではありません。医療データベースの一部には、EAV（エンティティ/属性/値）モデルに適した特性を備えています。

フロントエンドの視点からの回答：

1996年に私が共同執筆した実験的なサンフランシスコ州立大学のWebサービスが数年前にようやくインターネットの天国に行き、その時点で単一のブラウザー互換性修正プログラムを必要としなかったため; それはあなたの40年の目標のほぼ半分です。そして、1998年にスタンフォード研究所のプロジェクトのために作成したこのJavaScriptベースのフロントエンドは、数年後に派手なものに置き換えられましたが、元のUIが軽微な互換性修正で今日も実行できなかった理由はありません。

秘Theは、アプリが広くサポートされているW3C / ECMA標準のみを使用し、管理下でクリーンなデザインを使用するようにすることです。トレンディな90年代時代の技術で書かれた多くのWebアプリは今日ではうまく機能しないか、まったく機能しませんが、主要な標準規格で書かれた90年代時代のWebアプリは依然として機能します。彼らは古く見えるかもしれませんが、彼らは動作します。

ここでの目標は、サーバー上で起動し、誰も再び触れずに40年間そこにとどまるWebアプリを作成することではありません。数十年後もまだ使用できる基盤を構築することです。基盤をゼロから再構築することなく、新しい機能をサポートするために成長させることができます。

まず第一に、あなたは公式の標準にのみ、公式の標準にコーディングする必要があります。承認されたECMAScript標準の一部ではないJavaScript機能はありません。ES5.1は現在のバージョンであり、一般的にサポートされているため、ターゲットを設定しても安全です。同様に、現在のバージョンのHTML5、CSS、およびUnicodeが適しています。JavaScript、CSS3、またはHTMLの実験的な機能はありません（ベンダープレフィックスが付いているか、ブラウザ間で100％の同意がないもの）。また、ブラウザ固有の互換性ハッキングもありません。新しい機能は、標準になったら使用を開始でき、誰もが接頭辞なしでサポートします。

ES5のサポートはIE8以前をドロップすることを意味しますが、これはブラウザ固有のハッキングを必要とするので、数年後には役に立たなくなるでしょう。寿命を最大限に伸ばすために、ES5のStrict Modeをお勧めします。これにより、IE10およびその他すべての最新バージョンでのベースラインブラウザーの互換性が実際に設定されます。また、これらのブラウザーは、HTML5のフォーム検証およびプレースホルダー機能の多くをネイティブでサポートしており、非常に長い間役立ちます。

ECMAScriptの新しいエディションは古いバージョンとの互換性を維持しているため、現在の標準に従ってコードを記述すれば、今後の機能をより簡単に採用できます。たとえば、今後のclass構文を使用して定義されたクラスは、現在のconstructor.prototype構文で定義されたクラスと完全に互換性があります。そのため、開発者は5年間で、クラスごとに何も壊さずにファイルごとにES6形式に書き換えることができます。もちろん、優れた単体テストもあると仮定します。

第二に、特にアプリのコーディング方法を変更する場合は、流行のJavaScriptアプリフレームワークを避けてください。バックボーンが大流行し、SproutCoreとEmberが大流行し、今ではAngularが誰もが促進したいフレームワークです。これらは有用かもしれませんが、共通点もあります。新しいバージョンがリリースされ、その寿命が疑わしい場合、アプリが壊れたり、コードの変更が必要になることがよくあります。私は最近、Angular 1.1アプリを1.2に更新しましたが、かなり書き直す必要がありました。同様に、Backbone 2から3に移行するには、多くのHTMLの変更が必要です。規格には理由があるため動きが遅いですが、これらのフレームワークは速く動き、定期的に壊れるものがコストになります。

さらに、新しい公式標準では、古いフレームワークが陳腐化することが多く、そのようなフレームワークが発生すると、それらのフレームワークは変化します（変更を伴う）か、取り残されます。ECMAScript 6が批准され、すべてのブラウザが標準化されたPromiseクラスをサポートすると、世界の競合するすべてのpromiseライブラリに何が起こるか知っていますか？それらは廃止され、開発者は更新を停止します。適切なフレームワークを選択した場合、コードは十分に適応する可能性があります。不適切に推測した場合は、主要なリファクタリングを検討することになります。

したがって、サードパーティのライブラリまたはフレームワークを採用することを考えている場合は、今後削除するのがどれほど難しいかを自問してください。アプリをゼロから再構築せずに削除できないAngularのようなフレームワークである場合、40年のアーキテクチャでは使用できない良い兆候です。いくつかのカスタムミドルウェアで抽象化したサードパーティ製のカレンダーウィジェットの場合、交換には数時間かかります。

第三に、アプリの構造をきれいに整えます。アプリフレームワークを使用していない場合でも、開発者ツール、ビルドスクリプト、優れたクリーンデザインを利用できます。私は個人的にClosure Toolkitの依存関係管理のファンです。なぜなら、それは軽量であり、アプリのビルド時にオーバーヘッドが完全に削除されるからです。LessCSSとSCSSは、スタイルシートを整理したり、リリース用の標準ベースのCSSスタイルシートを構築したりするための優れたツールでもあります。

また、MVC構造を使用して、独自のコードを使い捨てのクラスに整理することもできます。これにより、数年先に戻って何かを書いたときに考えていたことを把握し、それを必要とする部分だけを交換することがはるかに簡単になります。

また、W3Cのアドバイスに従い、プレゼンテーション情報をHTMLから完全に排除する必要があります。（これには、「big-green-text」や「two-columns-wide」など、要素にプレゼンテーションクラス名を与えるなどのチートが含まれます。）HTMLがセマンティックでCSSがプレゼンテーションの場合、保守と調整がはるかに簡単になります。将来の新しいプラットフォームへ。また、目の不自由な人や障害のある人向けの専用ブラウザのサポートを簡単に追加できます。

第4に、テストを自動化し、ほぼ完全にカバーするようにします。サーバーサイドまたはJavaScriptであるかどうかにかかわらず、すべてのクラスの単体テストを記述します。フロントエンドでは、サポートされているすべてのブラウザーで、各クラスがその仕様に従って動作することを確認してください。コミットごとにビルドボットからこれらのテストを自動化します。これは、現在のブラウザでバグがわかりにくい場合でもバグを早期に発見できるため、寿命と信頼性の両方にとって重要です。JasmineとGoogle ClosureのJSUnitベースのテストフレームワークはどちらも優れています。

また、Selenium / WebDriverが得意な完全なUI機能テストを実行することもできます。基本的に、UIをステップスルーし、人がテストしているように使用するプログラムを作成します。それらもビルドボットに接続します。

最後に、他の人が言及したように、あなたのデータは王様です。データストレージモデルを熟考し、それが最後まで構築されていることを確認してください。データスキーマがしっかりしていることを確認し、すべてのコミットで徹底的にテストされていることを確認してください。また、サーバーアーキテクチャがスケーラブルであることを確認してください。これは、フロントエンドで行うことよりもさらに重要です。

クライアントの不合理な期待の問題を残して、設計の問題に焦点を当てて、私は40年まで行かないでしょうが、あなたが持っていると思われる問題は、長期的な進化可能性、まさにRESTが作成されたものです。それによって、私はRESTをアーキテクチャスタイルとして本当に意味します。最近の用語に非常に一般的に関連付けられている流行語駆動の開発ではありません。

私の論文にメディアタイプの設計に関する十分な詳細を含めることができなかったため、ある程度、人々はRESTを間違っています。それは私が時間を使い果たしたからであり、RESTの他の側面よりも重要性が低いと思ったからではありません。同様に、多くの人々は、信頼できる情報源に基づいていない主題のウィキペディアエントリのみを読むため、間違っていると思われます。

しかし、私はほとんどの人が単純なものを設計するのが簡単であるべきであるという間違いを犯すと思います。実際には、何かを設計するのに必要な労力は、結果の単純さに反比例します。アーキテクチャスタイルが進むにつれて、RESTは非常にシンプルになります。

RESTは数十年規模のソフトウェア設計です。すべての詳細は、ソフトウェアの寿命と独立した進化を促進することを目的としています。

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

RESTfulインターフェースを使用するつもりであると述べました。このコメント自体は、それについて真剣な調査を行い、RESTが実際に何であるかを理解しようとすることを示唆しています。おそらく、ほとんどの人がRESTと考えるCRUD操作へのHTTPメソッドのマッピングに関連付けているだけでしょうが、それとは何の関係もありません。

RESTは、Web自体のアーキテクチャの形式化と考えてください。何らかの形で、10年以上前に書かれたWebの多くの部分がまだ利用可能であり、今日作られたクライアントで使用できるため、その部門で何かを得ました。RESTを正しく実行するのは難しいが、長期的なメリットはそれだけの価値があるので、それは多くの作業になるでしょう。

質問と他の（非常によく考えられた）回答を読んだ後、私も2セントを残すと思いました。注：古いアプリケーション/ソフトウェアをメンテナンスする必要はまったくありません。参照として使用しているのは、オープンな政府データを取得し、さまざまな形式で解析して表示する、進行中の趣味用のWebアプリです。このアプリは、私だけではなく、政府がいつか何らかの形でこのデータを提供すると発表したプロジェクトとして始まりました。だから、多くのものが時間とともに変化することは明らかでした。そして彼らはやった。私が学んだこと：

• ミニアプリケーションで物事を分割します。それぞれが独自にタスクを完全に実行できます。これにより、1つのピースを非常に高速に、非常に安全に、非常に簡単に切り替えることができます。そして、あなたが戻って行かなければならないとき、それがなぜ起こるのか、どうやって起こるのかを回避するのは本当に難しいことではありません。あなたや他の誰かが後で何かを変更しなければならない場合、物事のセット全体よりも単一の部分を交換する方が簡単です。
• さまざまなパーツ間の通信に使用される、安定したミドルウェア/レイヤーを取得します。この場合、JSONを使用しましたが、XML、ini、または同様の標準でも問題ありません。繰り返すのは簡単で、ほとんど何にでも変換できます。いずれもかなりの期間存続する実証済みの標準です。基礎となるデータやストレージモデルが変更される場合でも。各アプリは、特定のタスクに独自のデータストレージを使用できます。これにより、タスクのスキャンデータの量が少なくなるため、処理と保守が容易になり、交換が容易になります。
• プログラミング言語の決定について心配する必要はありません。それらは時間とともに変化します。使いやすい言語、またはタスクに最適な言語を使用していることを確認してください。
• データストレージが「水平方向に拡張可能」であり、追加のストレージモジュールを簡単に接続できることを確認してください。
• ミニアプリが呼び出されたり、データを交換したりする共通点（私の場合はURI）を取得します。

要約すると、私が最も気にするのは、タスクに割り当てられたパーツの懸念と交換可能性の分離です。40年後（5年でも10年でも）に、ハードウェア、インターフェイス、ストレージなどが大きく変わることを知っているだけです。そして、後の開発者はこれらの変更に対応し、アプリケーションの一部（データコンテナまたはユーザーインターフェイスの一部）を交換する必要があります。

物事を可能な限り「将来に耐える」ものにするには、変更を計画します。つまり、簡単に変更できる機能以外には最適化しないように最大限の努力をしてください。したがって、正規化、厳密な検証、および疎結合の豊富さはありません。

• 主要なオープンソース技術を使用します。データについては、クローズドソースシステムが主要なリスク源です。これは、どの企業がデータのすべてのアクセス権を取得するかによって、どの企業が戦略を変更または変更するかを計画できないためです。また、活気のあるコミュニティのない小規模なオープンソースプロジェクトもサポートを失う可能性が高くなります。

• スキーマレスのNoSQLデータベースを使用します。使用されている非構造化データの種類は、MongoDBのようなドキュメントストアの教科書からほとんどそのままです。従来のリレーショナルデータベースとその正規化は、データがどのように構造化されるかを知っている場合には有効ですが、特にここでは特にフィクションです。RDBSでスキーマを変更するコストは、システムが拡大するにつれてますます大きくなります。現在選択されている構造が変化することを知ってください。

• 広く受け入れられている標準を使用して、システムを大幅に分離します。すべてのデータアクセスと突然変異をWebサービスに分割することは、これに向けた第一歩です。変更を送信するためのメッセージキューなどと組み合わせると、システムの個々の部分で言語や技術が時間とともに変化するのに役立ちます。

OK、だから私はここでいくつかのことを言うつもりだ。おそらくそれはかなり人気がなくなるだろうが、ここで私に固執する。

これはデータおよび/またはアプリケーションが20年以上続く最初のプロジェクトであり、あなたがプロジェクトをリードしているので、一歩後退して、このプロジェクトが成功する確率を検討する必要があります。 。基本的にゼロに近いからです。

データベースの設計に集中し、それを正しくするために膨大な時間を費やす必要があります。このプロジェクトを成功させるには、データアーキテクトをプロジェクトに参加させる必要があります。データベース設計の経験があり、将来どのようにデータを使用できるかを十分に熟知している人がいなければ、5年後でも40年後でもデータがまだ有用である可能性はほとんどありません。

2人（うち1人はjr。devという肩書きを持つ）が40年続くと予想されるゼロから何かを構築することを期待しても、おそらく成功しません。データデザイン、APIデザイン、アプリケーションデザインに取り組んでいるこのような大規模プロジェクトでの作業の経験が豊富な人々のチームが必要です。このようなものは2人のプロジェクトではありません。

このプロジェクトをDrupalのようなものに結び付けたいのは、なぜこの種のプロジェクトに取り組んでいる人々がプロジェクトに必要なのかを示しています。ほんの数年でスタイルが崩れるようなアプリケーションにアプリケーションを結び付けたくありません。そうした場合、5〜10年以内にシステムで作業する人を見つけることは非常に迅速に困難になる可能性があります。

このアドバイスを経営陣に伝え、プロジェクトにもっと多くの高齢者を引き入れる必要があることを説明します。そうしないと、プロジェクトは失敗する運命にあり、おそらくあなたはその責任を負うことになります。

アプリケーションは、進化なしで40年生き残る必要はありません。ただし、ゼロから構築するか、または構築する必要があるため、それでも「機能」している可能性があります。

最も重要なことは、拡張性だけでなく安定性とガバナンスを可能にする「データアーキテクチャ」です。

私たちは、人類の終わりをほぼ生き延びながらも拡張可能なデータアーキテクチャと分類法を設計しました。これを行うための真のデータ分類/データアーキテクチャ担当者を見つけました。

ここで重要なのは、データベースに焦点を当てることです（上記のいくつかで述べたように）。これは一貫性があり、操作を完全に記述する必要があります。変更に応じて、操作とともに成長する必要があります。変更するのが簡単でない場合、それは時代遅れになり、それは死のキスです。残りは比較的重要ではありません。

正規化は重要ではないことを示唆している上記の人々には同意しませんが、現在のシステムが仕事に合っていない場合が常にあります。これらの場合、非正規化を行いますが、データベースがアトミックトランザクションの一部として追加の書き込み/変更を処理するようにします。そうすれば、問題を修正できるまで、問題を効果的に無視できます。

私が退職前に働いていた会社は、ゼロから書かれたシステムを実行しており、25年にわたってほぼ継続的に成長し、中規模小売業者のほぼすべての側面をカバーしています。私が重要だと思うこのシステムの側面は次のとおりです。

• 統合は不可欠です。
• データベースは、ITスタッフと他のスタッフの両方にとって正確で理解しやすいものである必要があります。そのため、ほとんど偏執的な名前付けの強調が必要です。定義されたニーモニックのテーブルがあり、それらを組み合わせてテーブル名とフィールド名を作成します。すべての「コード」は同様に定数として名前が付けられ、EAVテーブル構造に格納されます。
• ビジネスロジックをデータベーストリガーにカプセル化しました。これは最初は苦痛であり、エラーメッセージをクライアントに送信し、一部のシステムでテーブル全体をロックせずにトリガーを柔軟に変更できるようにするための追加作業が必要ですが、これはすぐに膨大な時間の節約になり、データベースをより正確にする必要がありますそれ以外の場合より。
• 参照が正しいように「削除」された場合でも、システムの寿命の間、少なくとも参照テーブル（理想的には最速で最も重要性の低いトランザクションを除くすべて）を保持すると仮定します。
• 上記の理由により、一意の識別子とトランザクション番号は長期にわたってサイズを確認してください。（元々、私は引退するまで持続する必要があると冗談で言っていました）。

イベントソーシングとコマンドおよびクエリの責任分離を使用することをお勧めします。これは主に、あなたが確信できる唯一の事柄が既に現れたイベントだからです。新しいタイプのイベントが来るかもしれません。そのため、モデルに重きを置いても、これは時代遅れになることは間違いありません。すべてのリリースですべてのデータを移行するのは現実的ではありません。そのため、最良の方法は、現在のニーズに適合し、必要なたびにすでに記録されたイベントから計算されるモデルを用意し、そのモデルの現在の状態から計算されたイベントを渡すことです。

また、テストを念頭に置いてください。アプリケーションが現在から10年以内に使用されている場合、テスターは、想定されていることをまだ実行中であることを確認する必要があります。したがって、アプリケーションの統合テストをできるだけ簡単にします。