40年以上の寿命を持つWebアプリケーションの設計に関するアドバイス
シナリオ
現在、私はヘルスケアプロジェクトの一部です。その主な要件は、ヘルスケアプロバイダーがユーザーが生成したフォームを使用して、未知の属性を持つデータをキャプチャすることです。 2番目の要件は、データの整合性が重要であり、アプリケーションが40年以上使用されることです。現在、過去40年間のクライアントのデータをさまざまなソース（Paper、Excel、Accessなど）からデータベースに移行しています。今後の要件は次のとおりです。
- フォームのワークフロー管理
- フォームのスケジュール管理
- セキュリティ/ロールベースの管理
- レポートエンジン
- モバイル/タブレットのサポート
状況
わずか6か月で、現在の（契約された）アーキテクト/シニアプログラマーは「高速」アプローチを採用し、貧弱なシステムを設計しました。データベースが正規化されておらず、コードが結合されており、層には専用の目的がなく、データベースで「削除」を実行するBeanをいくつか設計しているため、データが失われ始めています。コードベースは非常に肥大化しており、データベースが正規化されていないため、データを同期するだけのジョブがあります。彼のアプローチは、欠落しているデータを復元するためにバックアップジョブに依存することであり、リファクタリングを信じていないようです。
調査結果を首相に提出したので、建築家は契約が終了すると解任されます。このアプリケーションを再構築するタスクが与えられました。私のチームは、私と1人のジュニアプログラマで構成されています。他にリソースはありません。このシステムの再構築に集中できる6か月の要件凍結が認められています。
DrupalのようなCMSシステムを使用することを提案しましたが、クライアントの組織でのポリシー上の理由から、システムはゼロから構築する必要があります。
寿命が40以上のシステムを設計するのはこれが初めてです。私は3〜5年の寿命のプロジェクトにのみ取り組んだので、この状況は非常に新しく、エキサイティングです。
質問
- どのような設計上の考慮事項により、システムはより「将来の証拠」になりますか？
- システムをより「将来を見据えた」ものにするために、クライアント/ PMにどのような質問をする必要がありますか？
データは王様
2013年頃のWebアプリケーションが2053年にまだ稼働していて実行可能であることを期待するのは少し不合理だと思います。テクノロジーは変化するでしょう。プラットフォームは行き来します。そのころには、HTMLは趣のある記憶かもしれません。しかし、あなたのデータはまだ残っています。
したがって、データが主な焦点です。あなたのデータがまだ存在している限り、人々はどんな新しいテクノロジーが生まれてもそれに適応することができます。データスキームがよく考えられており、拡張に適していることを確認してください。時間をかけてそれらを仕様化してください。
実際のアプリケーションに関しては、あなたの会社はおそらく「ゼロからビルド」ディレクティブを持っているという点で正しいでしょう。私は2、3年以上前のWebアプリをいくつか維持していますが、それらが2003年の一般的なCMSシステムにロックされていないことを非常に嬉しく思います。彼らは自家製の非常にシンプルなフレームワークを使用しています。このような場合は、プロジェクトのニーズに合わせて特別に作成する非常に基本的なフレームワークを使用する方がよいと思います。
しかし、現実には、40年以上にわたって、同社は（うまくいけば）進化するプラットフォームに対応するために、かなりの数のフロントエンドサービスとバックエンドサービスを作成することになります。そのため、個々のユーザー向けアプリケーションの寿命を5〜10年にすることを目標としています。
私たちは、20年以上にわたって顧客に支払って使用されてきたソフトウェアを製造しています。コードベースは、数世代のソース管理ツールよりも長持ちしました。私たちのソフトウェアは、タブレットのものを除いて、すべての箇条書きをヒットします。
懸念事項には、 [〜＃〜] esign [〜＃〜] および [〜＃〜] ueta [〜＃〜] が含まれます。私たちの弁護士は、少なくとも10年間は電子記録を読み取り可能に保つ必要があると考えています。全体が保持されているドキュメントについては、 PDF/A を調べる必要があります。
データベースについては、正規化についてあまり気にしないでください。代わりに、すべてをログに記録すること、およびデータの変更/削除を追跡する監査テーブルを用意することを考慮する必要があります。バージョンをアップグレードするときは、新しいバージョンを並行して十分な時間テストして、データが確実に移行されるように計画してください。この新しいバージョンのテストには、新しいオペレーティングシステムも含まれています。長年にわたって、非常に不愉快な驚きがありました。ロールバックを実行する必要がある場合に備えて、インストールメディアとライセンスキーを保持します。バックアップをテストします。オブジェクトをシリアル化してデータベースに格納する場合は、開発フレームワークによって提供されるシリアル化ではなく、XMLとして実行してください。
人員配置のために、長期的なコードベースには長期的なメモリが必要です。理想的には、長い間存在していた人々の周りが欲しいでしょう。それが制度的に不可能である場合は、wikiのようなものにすべてを文書化する必要があります。そして、私のアドバイスは、バグ追跡システムと連携できるwikiです。
コードベースについては、コードにコメントがあることを確認してください。あるバージョン管理システムから別のバージョン管理システムに移行すると、ほとんどの場合、チェックインコメントが失われます。私は仕様とバグ番号にちなんでユニットテストに名前を付けるのが好きです。そうすれば、単体テストTest_Bug_1235が失敗した場合に、何がどこでテストされているのかを追跡するために何がどこにあるかがわかります。テストにCheck_File_Save_Networked_Drivesという名前を付けるほど「セクシー」ではありませんが、そのようなテストはTest_requirement_54321_case_2とは異なり、仕様、要件、またはバグに戻るのが困難です。
20年後もこのアプリケーションがどのように動作するかを理解するのではなく、6か月をかけて、元の設計者が引き起こした問題を修正し、賢明で堅牢なアーキテクチャを導入し、そこから先に進みます。
データベースの部分的な非正規化は、医療現場では必ずしも完全に予期しないものではありません。医療データベースの一部には、 EAV（エンティティ/属性/値） モデルに適した特性を備えています。
フロントエンドの観点からの回答：
1996年に私が共同で書いた実験的なサンフランシスコ州立大学のWebサービスがついに数年前にようやくインターネットの天国に行き、その間に単一のブラウザー互換性修正を必要としないため;これは40年の目標のほぼ半分です。そして このJavaScriptベースのフロントエンド 1998年にStanford Research Instituteプロジェクトのために作成しましたが、数年後にはより派手なものに置き換えられましたが、元のUIが今日でも実行できなかった理由はありません。マイナーな互換性の修正。
秘訣は、アプリが広くサポートされているW3C/ECMA標準のみを使用し、制御されたクリーンなデザインであることを確認することです。トレンディな90年代時代のテクノロジー向けに作成された多くのウェブアプリはうまく機能しないか、まったく機能しませんが、主要な標準向けに作成された90年代時代のウェブアプリはまだ機能します。彼らは見栄えが悪いかもしれませんが、彼らは働きます。
ここでの目標は、サーバー上で動作し、40年間そこにとどまることができるWebアプリを作成することではなく、再び触れることはありません。それは、何十年も経ってもまだ使用可能な基盤を構築することです。基盤は、ゼロから再構築することなく、新しい機能をサポートするために成長することができます。
まず第一に、公式の標準に合わせてコーディングする必要がありますかつ公式の標準にのみコーディングしてください。承認されたECMAScript標準の一部ではないJavaScript機能はありません。 ES5.1は現在のバージョンであり、一般的にサポートされているため、ターゲットを設定しても安全です。同様に、HTML5、CSS、およびUnicodeの現在のバージョンも適切です。実験的なJavaScript、CSS3、またはHTML機能（ベンダープレフィックスが付いているもの、またはブラウザー間で100％の合意がないもの）はありません。また、ブラウザ固有の互換性ハックはありません。新しい機能が標準になり、誰もがプレフィックスなしでそれをサポートしたら、新しい機能を使い始めることができます。
ES5のサポートとはIE8以前を削除することを意味します。ブラウザ固有のハックが必要になるため、数年で役に立たなくなるためです。寿命が長くなる可能性が最も高い場合は、ES5のストリクトモードをお勧めします。これにより、ベースラインブラウザーの互換性が実際に IE10および他のすべての人の最新バージョン に設定されます。これらのブラウザーは、HTML5のフォーム検証とプレースホルダー機能の多くをネイティブでサポートしているため、非常に長い間役立ちます。
ECMAScriptの新しいエディションは古いバージョンとの互換性を維持しているため、コードが現在の標準に従って記述されている場合は、今後の機能をより簡単に採用できます。たとえば、今後のclass構文を使用して定義されたクラスは、現在のconstructor.prototype構文で定義されたクラスと完全に互換性があります。したがって、開発者は5年以内に、クラスをファイルごとにES6形式に書き換えることができ、何も壊すことはありません。もちろん、単体テストも適切だと仮定します。
2番目に、流行のJavaScriptアプリフレームワークを避けます特に、アプリのコーディング方法を変更する場合。バックボーンが大流行し、次にSproutCoreとEmberがそうでしたが、今やAngularは誰もが宣伝したいフレームワークです。それらは有用かもしれませんが、共通点もいくつかあります。アプリを壊して、必要とすることがよくあります。新しいバージョンが出て、その寿命が問題になると、コードが変更されます。最近Angular 1.1アプリを1.2に更新しました。かなり書き直す必要がありました。同様に、バックボーン2から3に移行するには、多くのHTMLの変更標準は理由により動きが遅いですが、これらのフレームワークは動きが速く、定期的に壊れるものがコストです。
さらに、新しい公式の標準では、古いフレームワークが古くなっていることが多く、その場合、それらのフレームワークは（重大な変更により）変化するか、取り残されます。 ECMAScript 6が承認され、すべてのブラウザーが標準化されたPromiseクラスをサポートすると、世界中の競合するPromiseライブラリはどうなるでしょうか。それらは時代遅れになり、開発者はそれらの更新を停止します。適切なフレームワークを選択した場合、コードは十分に適応する可能性があり、推測が不十分な場合は、主要なリファクタリングを検討することになります。
したがって、サードパーティのライブラリまたはフレームワークを採用することを考えている場合は、将来削除することがどれほど難しいかを自問してください。 Angularのようなフレームワークであり、アプリを最初から再構築しないと削除できない場合は、40年のアーキテクチャで使用できないことを示す良い兆候です。3番目の場合いくつかのカスタムミドルウェアで抽象化したサードパーティのカレンダーウィジェットを置き換えると、数時間かかります。
番目に、優れたクリーンなアプリ構造を提供します。アプリフレームワークを使用していない場合でも、開発者ツール、ビルドスクリプト、および優れたクリーンなデザインを利用できます。私は個人的には、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の他の側面同様に、信頼できるソースに基づいていない、件名のWikipediaエントリーのみを読み取るため、多くの人が誤解していると思います。
しかし、ほとんどの人は、単純なものを設計するのは簡単であるべきだと誤解しているだけだと思います。実際には、何かを設計するために必要な労力は、結果の単純さに反比例します。建築スタイルが進むにつれて、RESTは非常に単純です。
RESTは数十年規模のソフトウェア設計です：すべての詳細は、ソフトウェアの寿命と独立した進化を促進することを目的としています。
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724
RESTfulインターフェースを使用するつもりであると述べました。そのコメント自体は、いくつかの真剣な調査を行い、RESTが実際に何についてであるかを理解することを試みる必要があることを示唆しています。おそらくそれを、HTTPメソッドのCRUD操作へのマッピングと単に関連付けているだけです。人々はRESTはそうだと思いますが、それはそれとは何の関係もありません。
RESTをWeb自体のアーキテクチャの形式化と考えてください。いずれにしても、10年以上前に書かれたWebの多くの部分がまだ利用可能であり、今日作成されたクライアントで使用されていたので、その部門で適切な結果が得られました。REST正しいことは難しいが、長期的なメリットがあるため、かなりの作業になると思います。それだけの価値があります。
質問と他の（十分に考え抜かれた）回答を読んだ後、2セントも残しておくと思いました。注：本当に古いアプリケーション/ソフトウェアを維持する必要はまったくありません。私が参照として使用しているのは、いくつかのオープンな政府データを取得し、解析してさまざまな形式で表示する、自分の進行中の趣味Webアプリです。アプリは私が一人ではなかったプロジェクトとして始まり、政府がこのデータを提供することを発表したとにかくどこかで。したがって、時間の経過とともに多くのことが変化することは明らかでした。そして彼らはそうした。私がそれから学んだこと：
- ミニアプリケーションで物事を分割します。それぞれが独自にタスクを完全に実行できます。これにより、単一のピースを非常に速く、非常に安全かつ簡単に切り替えることができます。そして、元に戻らなければならない場合、なぜ物事が発生するのか、どのように発生するのかを理解するのはそれほど難しくありません。あなたや他の誰かが後で何かを変更する必要がある場合は、全体のセットよりも単一のパーツを交換する方が簡単です。
- 異なるパーツ間の通信に使用される堅実な一定のミドルウェア/レイヤーを取得します。この場合、JSONを使用しましたが、XML、ini、または同様の標準でも問題ありません。繰り返すのは簡単で、ほとんど何にでも変えることができます。すべてがかなり長い間存続する実証済みの標準です。基盤となるデータやストレージモデルが変更される場合でも。各アプリは、特定のタスクに独自のデータストレージを使用できます。これにより、タスクのスキャンされたデータの量が少なくなるため、処理と保守が容易になり、交換が容易になります。
- プログラミング言語の決定について心配する必要はありません。それらは時間とともに変化します。使いやすい言語、または作業に最も適した言語を使用していることを確認してください。
- データストレージが "horizontally scaleable" であること、および追加のストレージモジュールを簡単に接続できることを確認してください。
- ミニアプリが呼び出されたり、データを交換したりする共通のポイント（私の場合はURI）を取得します。
まとめ：私が最も気にかけているのは、タスクに割り当てられているパーツの分離と交換可能性です。 40年後には（5年または10年でも）ハードウェア、インターフェース、ストレージなどが大幅に変化することを知っています。そして、後の開発者は、それらの変更に対応し、データコンテナーであろうとユーザーインターフェイスの一部であろうと、アプリケーションの一部を交換する必要があります。
可能な限り「将来に備えた」ものにするために、変更を計画します。つまり、簡単に変更できる機能以外の最適化を行わないようにしてください。したがって、正規化、厳密な検証、および疎結合の膨大さはありません。
主要なオープンソース技術を使用します。データの場合、クローズドソースシステムはリスクの主要な原因です。データへのすべてのアクセスを考慮に入れて、企業が戦略を練ったり、戦略を変更したりすることは計画できないからです。また、活発なコミュニティのないマイナーなオープンソースプロジェクトもサポートを失う可能性が高くなります。
スキーマレスのNoSQLデータベースを使用します。使用されている種類の非構造化データは、MongoDBのようなドキュメントストアの教科書にはほとんど含まれていません。従来のリレーショナルデータベースとその正規化は、データがどのように構造化されるかを知っている場合に適していますが、これは特にここではフィクションです。システムが拡張するにつれて、RDBSのスキーマを変更するコストはますます大きくなります。現在選択されている構造が変化することを知ってください。
広く受け入れられている標準を使用して、システムを大きく切り離します。すべてのデータアクセスを分割してWebサービスに変換することは、これに向けた1つのステップです。これを変更を送信するためのメッセージキューなどと組み合わせることで、システムの個々の部分が言語やテクノロジーを徐々に変更するのに役立ちます。
わかりましたので、ここではおそらくかなり不人気になるいくつかのことを言いますが、ここに固執します。
これは、データまたはアプリケーション、あるいはその両方が20年以上続くことが想定されている最初のプロジェクトであり、あなたがプロジェクトを主導しているので、一歩下がって、このプロジェクトが成功する確率を考える必要があります。 。基本的にゼロに近いからです。
データベースの設計に集中し、それを正しく行うために、膨大な時間を費やす必要があります。このプロジェクトを成功させるには、データアーキテクトをプロジェクトに参加させる必要があります。データベース設計の経験があり、将来データがどのように使用されるかを楽しみに実践している人がいなければ、5年後も40年後もデータがまだ有用である確率は誰にもほんのわずかです。
2人（そのうちの1人はjr。devのタイトルを持っている）が、40年続くと予想されるゼロから何かを構築することを期待していても、おそらく成功しないでしょう。このような大規模なプロジェクトでの経験があり、データ設計、API設計、およびアプリケーション設計に取り組んでいる人々のチームが必要です。このようなものは2人のプロジェクトではありません。
Drupal=のようなものにプロジェクトを関連付けたいと思うことは、プロジェクトがこれらの種類のプロジェクトで作業することに慣れている人々を必要とする理由を示します。アプリケーションを、実行される可能性のあるものに関連付けたくないのです。ほんの数年でスタイルが変わります。もしそうした場合、5〜10年でシステムに取り組む人を見つけるのは非常に困難になります。
私はこのアドバイスを経営陣にとり、プロジェクトにより多くの高齢者を獲得する必要があることを彼らに説明します。そうでなければ、プロジェクトは失敗する運命にあり、あなたはおそらくそれを非難する責任者になるでしょう。
アプリケーションは、進化することなく40年存続する必要はありません。ただし、ゼロから構築するか、または構築する必要があるため、「機能」している可能性があります。
最も重要なことは、拡張性だけでなく、安定性とガバナンスを可能にする「データアーキテクチャ」です。
私たちは、人類の終わりを生き延びても、拡張性を維持できるデータアーキテクチャと分類法を設計しました。あなたはあなたのためにこれを行う真のデータ分類/データアーキテクチャ担当者を見つけました。
ここでの鍵は、データベースに焦点を当てることです（上記のいくつかが言ったように）。これは一貫性があり、操作を完全に記述する必要があります。変化に応じて、操作とともに成長する必要があります。変更が容易でない場合、古くなり、それは死のキスです。残りは比較的重要ではありません。
現在のシステムではうまくいかない場合が常にあるものの、正規化は重要ではないと示唆している上記の人々には同意しません。これらの場合、非正規化しますが、データベースがアトミックトランザクションの一部として追加の書き込み/変更を処理するようにします。そうすることで、修正できるまで効果的に問題を無視できます。
私が退職する前に働いていた会社は、ゼロから書かれたシステムを実行しており、25年間ほぼ継続的に成長しており、中規模の小売業者のほぼすべての側面をカバーしています。このシステムの重要な点は次のとおりです。
- 統合は不可欠です。
- データベースは、ITスタッフと他のスタッフの両方にとって同じくらい正確で理解可能である必要があるため、命名にほとんど偏執的な強調が必要です。定義されたニーモニックのテーブルがあり、それらを組み合わせてテーブル名とフィールド名を作成します。すべての「コード」も同様に定数として名前が付けられ、EAVテーブル構造に保存されます。
- ビジネスロジックをデータベーストリガーにカプセル化しました。これは最初は苦痛であり、エラーメッセージをクライアントに送信し、一部のシステムでテーブル全体をロックせずにトリガーを柔軟に変更できるようにするには、追加の作業が必要ですが、これはすぐに大幅な時間の節約になり、データベースをより正確にする必要がありますそれ以外の場合より。
- 「削除」しても参照が正しい場合でも、システムの存続期間中は少なくとも参照テーブル（理想的には最速で最も重要でないトランザクションを除くすべて）を保持するとします。
- 上記の理由により、一意の識別子とトランザクション番号が長期にわたってサイズ設定されていることを確認してください。 （私はもともと冗談めかして、私が引退するまでそれらを持続させる必要があることを示唆していました）。
イベントソース および コマンドとクエリの責任の分離 を使用することをお勧めします。これは主に、確実に確認できるのはすでに表示されているイベントだけだからです。新しいタイプのイベントが来るかもしれません。ですから、モデルを深く考えても、時代遅れになることは間違いありません。リリースごとにすべてのデータを移行することは、現実的ではない場合があります。したがって、現在のニーズに適合し、必要に応じて既に記録されているイベントから計算されるモデルを用意し、そのモデルの現在の状態から計算されたイベントを渡すのが最善です。
テストも念頭に置いてください。アプリケーションが今から10年以内に使用されている場合、テスターはそれが本来の動作をしていることを確認する必要があります。したがって、アプリケーションの統合テストをできるだけ簡単にします。