タグ付けされた質問 「design」

単純なWebサイト、たとえば連絡先を追加、削除、更新できる連絡先帳を作成するindex.phpとき、ユーザーがログインしていない場合はパスワードを入力し、正しいパスワードを入力した場合はユーザーに入力するファイルを作成しますセッションを割り当て、連絡先と特定のことを行うことができます。 2つのファイルがあります。 最初の（contacts.php）はHTMLコードを表示するためのものです。HTMLコードの上に、2番目のファイルを含めてクラスを作成します。 2番目（contacts_class.php）には、追加、削除、および更新のためのすべてのメソッドが含まれています。 大丈夫だと思いますが、大きなプロジェクトを実装する場合、どうすればいいですか？すべてのページにフォルダーを作成し、それらにファイルを配置する必要がありますか（上記、HTML、クラスなど）、どうすればよいですか？他のすべてのプログラマーが完全に理解するような大規模プロジェクトを構築するのに適した、きちんとしたアーキテクチャとは何ですか？

28 design  php  architecture 

私は、世界中のさまざまな顧客向けに高度にカスタマイズされた大規模なソフトウェアプロジェクトに取り組んでいます。つまり、80％のコードがさまざまな顧客に共通しているだけでなく、ある顧客から別の顧客に変更する必要がある多くのコードがあることを意味します。過去に別のリポジトリ（SVN）で開発を行い、新しいプロジェクトが開始されたとき（大規模な顧客はほとんどありませんが）、過去のプロジェクトがニーズに最適なコードベースに基づいて別のリポジトリを作成しました。これは過去に機能していましたが、いくつかの問題に遭遇しました。 あるリポジトリで修正されたバグは、他のリポジトリでは修正されません。これは組織の問題かもしれませんが、5つの異なるリポジトリのバグを修正してパッチを当てるのは難しいと思います。このリポジトリを保守しているチームは世界の別の場所にいて、テスト環境がないことに注意してください、スケジュールや要件を把握していません（ある国の「バグ」は別の国の「機能」かもしれません）。 別のプロジェクトにも役立つかもしれない1つのプロジェクトに加えられた機能と改善は失われ、別のプロジェクトで使用された場合、多くの場合、1つのコードベースから別のコードベースにそれらをマージする大きな頭痛の種を引き起こします）。 1つの開発ブランチで行われたリファクタリングとコードの改善は、ブランチ間でこれらのすべての変更をマージする必要がある場合、失われるか、害よりも害をもたらします。 現在、これらの問題を解決する方法について議論しており、これまでのところ、これを解決する方法について次のアイデアを思いつきました。 開発を別々のブランチで維持しますが、一般的なバグ修正がマージされる中央リポジトリを持ち、すべてのプロジェクトがこのセントラルリポジトリからの変更を定期的に（たとえば毎日）独自のものにマージすることで、より整理されます。これには、大きな規律と、ブランチ間のマージに多大な労力が必要です。ですから、特に時間のプレッシャーがかかったときに、それがうまくいくと確信していません。 個別の開発ブランチを放棄し、すべてのコードが存在する中央のコードリポジトリを持ち、プラグ可能なモジュールと構成オプションを使用してカスタマイズを行います。既にコードの依存関係を解決するためにDependency Injectionコンテナーを使用しており、ほとんどのコードでMVVMパターンに従ってビジネスロジックをUIから明確に分離しています。 2番目のアプローチはよりエレガントに見えますが、このアプローチには多くの未解決の問題があります。例：モデル/データベースでの変更/追加の処理方法。エンティティフレームワークで.NETを使用して、エンティティを厳密に型指定しています。ある顧客には必要だが、データモデルを乱雑にすることなく別の顧客には役に立たないプロパティをどのように処理できるかわかりません。サテライトテーブル（特定のエンティティ用の追加の列が元のエンティティへの1：1マッピングで存在する個別のテーブルを持つ）を使用してデータベースでこれを解決することを考えていますが、これはデータベースのみです。これをコードでどのように処理しますか？データモデルは中央ライブラリにあり、このアプローチを使用して顧客ごとに拡張することはできません。 この問題に苦しんでいるのは私たちだけではないと確信しており、このトピックに関する資料がほとんどないことにショックを受けています。 私の質問は次のとおりです。 高度にカスタマイズされたソフトウェアに関してどのような経験があり、どのアプローチを選択し、どのように機能しましたか？ どのアプローチをお勧めしますか、またその理由は何ですか？より良いアプローチはありますか？ お勧めできるトピックに関する良い本や記事はありますか？ 技術環境（.NET、Entity Framework、WPF、DI）について具体的な推奨事項はありますか？ 編集： すべての提案をありがとう。アイデアのほとんどは、すでにチーム内で持っていたものと一致しますが、あなたがそれらで得た経験と、それらをより良く実装するためのヒントを確認することは本当に役立ちます。 どの方向に進むかはまだわかりませんし、（単独で）決定を下すわけではありませんが、チームでこれを伝えて、役に立つと確信しています。 現時点では、テナーはさまざまな顧客固有のモジュールを使用する単一のリポジトリのようです。私たちのアーキテクチャがこれに合っているか、それを適合させるためにどれだけ投資する必要があるのか​​はわかりません。 それで、すべての応答に再び感謝します！

28 design  architecture  development-process  database-design  code-organization 

例外を設計するとき、ユーザーまたは開発者が理解する必要があるメッセージを作成する必要がありますか？実際に例外メッセージの読者はだれですか？ 例外メッセージはまったく役に立たないと思うし、いつも書くのに苦労しています。慣例により、例外のタイプは既に何かが機能しなかった理由と、カスタムプロパティがファイル名、インデックス、キーなどの情報をさらに追加する理由を既に示しているはずです。自動生成されたメッセージでも実行でき、含まれる必要があるのは、追加のプロパティのリストを含む例外の名前だけです。これは、手書きのテキストとまったく同じように便利です。 メッセージをまったく書き込まずに、コードでハードコーディングするのではなく、おそらく異なる言語で意味のあるメッセージを作成する特別な例外レンダラーを用意する方が良いと思いませんか？ これらの質問のいずれかが私の質問に対する答えを提供するかどうか尋ねられました： 適切な例外メッセージを書く方法 多くの例外メッセージに有用な詳細が含まれていないのはなぜですか？ 私は両方を読みましたが、彼らの答えに満足していませんでした。彼らは一般的にユーザーについて話し、宛先ではなくメッセージ自体の内容に焦点を当て、エンドユーザーと開発者の少なくとも2人が存在することがわかりました。例外メッセージを書くとき、私はどちらに話すべきかわかりません。 有名なメッセージは、例外タイプの名前を異なる単語で繰り返しているだけなので、実際の価値はまったくないと思います。完全に自動生成できます。 私にとって例外メッセージは、読者の差別化に欠けています。完璧なエンドユーザー用と開発者のための1：例外は、メッセージの少なくとも2つのバージョンを提供する必要があります。単なるメッセージと呼ぶのは一般的すぎます。その後、開発者のメッセージは英語で記述する必要がありますが、エンドユーザーのメッセージは他の言語に翻訳する必要がある場合があります。このすべてを1つのメッセージだけで実現することは不可能であるため、例外は、先ほど述べたように、さまざまな言語で利用できるエンドユーザーメッセージに識別子を提供する必要があります。 リンクされている他のすべての質問を読むと、例外メッセージは実際には開発者ではなくエンドユーザーが読むことを意図しているという印象を受けます... 1つのメッセージはケーキを食べて食べるようなものです。

27 design  exceptions 

「システムをモジュールに分解する際に使用する基準について」という古典的な記事がありますが、これは初めて読んだばかりです。それは私にとって完全に理にかなっており、おそらくOOPのベースとなった記事の1つです。その結論： これらの例により、フローチャートに基づいてシステムのモジュールへの分解を開始することはほとんど常に間違っていることを実証しようとしました。...各モジュールは、そのような決定を他のモジュールから隠すように設計されています 私の無学で経験の浅い意見では、関数型プログラミングはこの記事の正反対のアドバイスを取ります。私の理解では、関数型プログラミングはデータフローを慣用的にします。データは関数から関数に渡され、各関数はデータを密接に認識し、途中で「変更」します。そして、データの隠蔽が過大評価されているか、不必要であるか、または何かについて話しているリッチヒッキーのトークを見たことがあると思いますが、確かに思い出せません。 まず、私の評価が正しいかどうか知りたいです。FPパラダイムとこの記事は哲学的に同意しませんか？ 彼らが同意しないと仮定すると、FPはデータ隠蔽の欠如をどのように「補償」しますか？おそらく、データ隠蔽を犠牲にしてX、Y、およびZを獲得する可能性があります。X、Y、およびZがデータ隠蔽よりも有益である理由を知りたいのです。 または、両者が同意しないと仮定すると、FPはデータの非表示が悪いと感じるかもしれません。もしそうなら、なぜデータ隠蔽が悪いと思うのですか？ 彼らが同意すると仮定して、FPがデータ隠蔽の実装とは何かを知りたいです。OOPでこれを見るのは明らかです。privateクラス外の誰もアクセスできないフィールドを持つことができます。FPの場合、これについての明らかな類推はありません。 質問すべき他の質問もあると思いますが、質問すべきかはわかりません。それらにも自由に答えてください。 更新 このNeal Fordの講演には、非常に関連性の高いスライドが含まれています。ここにスクリーンショットを埋め込みます。

27 design  object-oriented  functional-programming  object-oriented-design 

継承、ポリモーフィズム、およびカプセル化は、OOPの3つの最も明確で重要な機能であり、それらから、最近では継承に高い使用統計があります。私はJavaScriptを学んでいますが、ここでは彼らはすべてプロトタイプ継承を持っていると言い、どこでも人々はそれが古典的な継承とはまったく異なるものだと言います。 しかし、実際の使用の点との違いは理解できませんか？つまり、基本クラス（プロトタイプ）を定義し、そこからいくつかのサブクラスを派生させると、どちらも基本クラスの機能にアクセスでき、派生クラスの機能を拡張できます。私が言ったことを継承の意図した結果であると考える場合、プロトタイプバージョンとクラシックバージョンのどちらを使用しているのかを気にする必要があるのはなぜですか？ さらに明確にするために、プロトタイプ継承と従来の継承の有用性と使用パターンに違いは見られません。その結果、両者が同じものであるOOADをもたらすため、それらが異なる理由を学ぶことに興味がありません。プロトタイプの継承は、実際には（理論的にではなく）古典的な継承とどの程度異なりますか？

27 design  object-oriented-design  inheritance 

ユーザーインターフェイスについて知る必要があるかもしれないクラスを作成する場合のベストプラクティスは何ですか。自分自身を描画する方法を知っているクラスは、ユーザーインターフェイス（コンソール、GUIなど）に依存するため、いくつかのベストプラクティスを破らないでしょうか。 多くのプログラミングの本で、継承を示す「形状」の例を見つけました。基本クラスのシェイプには、円や正方形などの各シェイプがオーバーライドするdraw（）メソッドがあります。これにより、ポリモーフィズムが可能になります。しかし、draw（）メソッドは、ユーザーインターフェースに大きく依存していませんか？たとえば、Win Forms用にこのクラスを記述した場合、コンソールアプリまたはWebアプリに再利用することはできません。これは正しいです？ 質問の理由は、クラスが最も役立つようにクラスを一般化する方法に常に固執し、ハングアップしていることに気付くからです。これは実際に私に対して働いており、私は「一生懸命やっている」のだろうかと思っています。

27 design 

SOLIDが何を達成することになっているのかを理解し、モジュール性が重要であり、その目標が明らかに役立つ状況で定期的に使用します。ただし、次の2つの理由により、コードベース全体に一貫して適用できません。 時期尚早な抽象化を避けたい。私の経験では、具体的なユースケース（現在または近い将来に存在する種類）なしで抽象化ラインを描画すると、間違った場所に描画されます。このようなコードを変更しようとすると、抽象化ラインが助けになるのではなく邪魔になります。したがって、どこに有用なのかがよくわかるまで、抽象化ラインを描画しないという側面を誤解する傾向があります。 私のコードをより冗長にし、理解しにくくするなど、重複を排除しない場合、モジュール性を高めることを正当化するのは難しいと思います。フローが単純で線形であるため、非常に適切にファクタリングされたラビオリコードよりも、シンプルで密結合された手続き型またはGodオブジェクトコードの方が理解しやすい場合があります。書くのもずっと簡単です。 一方、この考え方はしばしば神の対象につながります。私は通常、これらを控えめにリファクタリングし、明確なパターンが出現する場合にのみ明確な抽象化ラインを追加します。明らかにモジュール性を必要とせず、大幅な重複がなく、コードが読み取り可能な場合、Godオブジェクトと密結合コードで何か問題があるとしたらどうでしょうか。 編集：個々のSOLID原則に関しては、Liskov Substitutionは常識の形式化であり、どこにでも適用されるべきであると強調するつもりでした。また、すべてのクラスは、何らかの抽象化レベルで単一の責任を負う必要がありますが、実装の詳細がすべて1つの巨大な2,000行クラスに詰め込まれた非常に高いレベルかもしれません。基本的に、抽象化は、抽象化を選択した場所で意味をなす必要があります。モジュール性が明確に役に立たない場合に私が疑問に思う原則は、オープンクローズ、インターフェース分離、特に依存関係の逆転です。これらは抽象化が意味をなさないだけでなく、モジュール性に関するものだからです。

27 design  object-oriented  solid 

技術系ではないビジネスマンから要件を引き出すのに最適な方法は何ですか？ プロジェクトの仕様をまとめようとしているチームと協力しています。私たちが会い、次の会議への期待に至るたびに、私たちはビジネスの人々に彼らの要求を取り戻すように頼みます。通常、彼らは次のような反応を示します。「さて、来週私たちが好きなものを見ることができるようにプロトタイプを作り上げることができると思いますか？ 6か月以上のプロジェクトであるため、明らかに実行不可能です（全体を開発する必要があります！）。また、なんらかの仕様なしにプロトタイプを作成する方法さえ知りません。率直に言って、私はほとんどの人と同じように、彼らは自分が望むものについてある程度の考えを持っていると思います。単純に伝える代わりに、「あなたが欲しいものを与えてください、または私たちは仕事をすることができない/できない」（結果に満足してもらいたい）、彼らが望むものを決めるのを助ける方法はありますか？たとえば、次のように伝えることができます。 「表示したいすべてのデータとマージンの機能の説明とともに、希望するUIを表示する画面（Powerpoint、ナプキンなど）を描画します。これから、私たちはそれを洗練し、この一連の動作要件に基づいてバックエンドを構築します。」 または 「今どのように見えるか心配する必要はありません（1番が電話を切ります）。プログラムが追跡する各項目について必要なすべてのデータのリストを提供してください。「顧客」の場合、名前、住所、電話番号、注文などをリストすることができます。完璧なデータベース構造である必要はありませんが、これから何かを見つけて、あなたが探しているもののアイデアを得ることができます。 これらの代替アプローチのいずれかは、ビジネスの人々に彼らが望むものに焦点を当てさせるのに意味がありますか？実際に見た代替手段はありますか？

27 design  business  requirements 

循環的複雑度のカテゴリーは何ですか？例えば： 1-5：維持しやすい 6-10：難しい 11-15：非常に難しい 20+：近づきにくい 何年もの間、私は10が制限であるという仮定を行ってきました。そしてそれ以上のものは悪いです。私は解決策を分析しており、コードの品質を判断しようとしています。確かに循環的な複雑さだけが測定値ではありませんが、それは役立ちます。循環的複雑度が200以上のメソッドがあります。私はそれがひどいことを知っていますが、上の例のように、より低い範囲について知りたいです。 私はこれを見つけました： カーネギーメロンの前述の参照値は、循環的複雑度値の4つの大まかな範囲を定義しています。 1から10までの方法はシンプルで理解しやすいと考えられます 10から20の間の値は、より複雑なコードを示しますが、依然として理解しやすいかもしれません。ただし、コードが取り得る分岐の数が多いため、テストはより難しくなります。 20以上の値は、非常に多数の潜在的な実行パスを持つ典型的なコードであり、非常に困難かつ労力をかけてのみ完全に把握およびテストできます。 50を超えるなど、さらに高くなるメソッドは確かに維持できません ソリューションのコードメトリックを実行すると、25未満の場合に結果が緑色で表示されます。これには同意しませんが、他の入力を取得することを望んでいました。 サイクロマティックの複雑性について一般に受け入れられている範囲リストはありますか？

26 design  programming-practices  metrics 

私がより良い開発者になったので、私の設計スキルの多くは、機械的分析よりも直感から来ていることがわかります。これは素晴らしい。これにより、コードを読んで、すばやく感じられるようになります。これにより、言語と抽象化の間でデザインをはるかに簡単に翻訳できます。そして、それは私がより速く物事を成し遂げることを可能にします。 欠点は、特定の設計が有利な理由をチームメイト（さらに悪いことに、経営陣）に説明するのが難しいことです。特に、ベストプラクティスの時代遅れのチームメイト。「この設計はテスト可能です！」または「継承よりも合成を優先する必要があります。」彼らの頭を真っ直ぐに行き、最後の10年のソフトウェアエンジニアリングの進歩に誰もが手がかりを与えようとする私のうさぎの穴に導かれます。 もちろん、練習すれば良くなりますが、その間に多くの無駄な時間や悪い設計が必要になります（後で修正するために無駄な時間がかかることになります）。利点が視聴者に完全に明らかではない場合、特定のデザインが優れている理由をよりよく説明するにはどうすればよいですか？

26 design  communication 

私が管理している新しいチームでは、コードの大部分はプラットフォーム、TCPソケット、およびhttpネットワークコードです。すべてのC ++。その大部分は、チームを去った他の開発者からのものです。チームの現在の開発者は非常に賢いですが、ほとんどの場合、経験的には後輩です。 私たちの最大の問題：マルチスレッドの同時実行バグ。ほとんどのクラスライブラリは、いくつかのスレッドプールクラスを使用して非同期に作成されています。クラスライブラリのメソッドは、長時間実行されるタスクを1つのスレッドからスレッドプールにキューイングすることが多く、そのクラスのコールバックメソッドは別のスレッドで呼び出されます。その結果、誤ったスレッドの仮定に関連する多くのエッジケースバグがあります。これにより、同時実行性の問題から保護するための重要なセクションとロックを保持するだけでなく、微妙なバグが発生します。 これらの問題をさらに困難にしているのは、修正の試みがしばしば間違っていることです。チームが（またはレガシーコード自体で）試みようとしているミスには、次のようなものがあります。 よくある間違い＃1-共有データをロックするだけで同時実行の問題を修正しますが、メソッドが期待される順序で呼び出されない場合に何が起こるかを忘れます。これは非常に簡単な例です： void Foo::OnHttpRequestComplete(statuscode status) { m_pBar->DoSomethingImportant(status); } void Foo::Shutdown() { m_pBar->Cleanup(); delete m_pBar; m_pBar=nullptr; } そのため、OnHttpNetworkRequestCompleteの実行中にShutdownを呼び出すことができるバグがあります。テスターはバグを見つけ、クラッシュダンプをキャプチャし、バグを開発者に割り当てます。彼は次のようにバグを修正します。 void Foo::OnHttpRequestComplete(statuscode status) { AutoLock lock(m_cs); m_pBar->DoSomethingImportant(status); } void Foo::Shutdown() { AutoLock lock(m_cs); m_pBar->Cleanup(); delete m_pBar; m_pBar=nullptr; } 上記の修正は、さらに微妙なエッジケースがあることに気付くまでは問題ありません。OnHttpRequestCompleteがコールバックされる前にシャットダウンが呼び出されるとどうなりますか？私のチームが持っている実際の例はさらに複雑であり、コードレビュープロセス中にエッジケースを見つけるのはさらに困難です。 よくある間違い＃2-盲目的にロックを終了し、他のスレッドが終了するのを待ってからロックを再入力することで、デッドロックの問題を修正します。 よくある間違い＃3-オブジェクトは参照カウントされますが、シャットダウンシーケンスはポインターを「解放」します。しかし、まだ実行中のスレッドがそのインスタンスを解放するのを待つことを忘れています。そのため、コンポーネントは完全にシャットダウンされ、その後、コールを予期しない状態のオブジェクトでスプリアスまたはレイトコールバックが呼び出されます。 他のエッジケースもありますが、一番下の行はこれです： マルチスレッドプログラミングは、頭のいい人でも簡単です。 これらの間違いを見つけると、より適切な修正を開発するために各開発者とエラーについて話し合うことに時間を費やします。しかし、「正しい」修正には触れなければならない膨大な量のレガシコードのため、各問題の解決方法についてしばしば混乱していると思われます。 私たちはすぐに出荷するつもりであり、私たちが適用しているパッチは今後のリリースに適用されると確信しています。その後、コードベースを改善し、必要に応じてリファクタリングする時間があります。すべてを書き直す時間はありません。そして、コードの大部分はそれほど悪くはありません。しかし、スレッドの問題を完全に回避できるように、コードをリファクタリングしたいと考えています。 私が検討しているアプローチの1つはこれです。重要なプラットフォーム機能ごとに、すべてのイベントとネットワークコールバックがマーシャリングされる専用の単一スレッドを用意します。メッセージループを使用したWindowsでのCOMアパートメントスレッドに似ています。長時間のブロッキング操作はワークプールスレッドにディスパッチされる可能性がありますが、コンポーネントのスレッドで完了コールバックが呼び出されます。コンポーネントは同じスレッドを共有することさえできます。その後、スレッド内で実行されるすべてのクラスライブラリは、単一のスレッド化された世界を想定して記述できます。 その道を進む前に、マルチスレッドの問題に対処するための他の標準的な手法や設計パターンがあるかどうかにも非常に興味があります。そして、私は強調しなければなりません-ミューテックスとセマフォの基本を説明する本を超えた何か。どう思いますか？ また、リファクタリングプロセスに向けた他のアプローチにも興味があります。次のいずれかを含む： スレッド周辺のデザインパターンに関する文献または論文。ミューテックスとセマフォの紹介を超えたもの。大規模な並列処理も必要ありません。他のスレッドからの非同期イベントを正しく処理するようにオブジェクトモデルを設計する方法だけです。 さまざまなコンポーネントのスレッド化を図式化する方法。これにより、ソリューションの研究と発展が容易になります。（つまり、オブジェクトおよびクラス全体のスレッドを議論するためのUML同等物） …

26 design  c++  architecture  multithreading 

優れたアナライザーおよびデザイナーになることは、開発者に大きな利益をもたらします。しかし、これには間違いなく障害があります。誰もがOOADに興味があるわけではなく、興味のあるすべての人が経路を知っているわけでもありません。優れたOOADは複数のOO言語を知っているべきですか？または彼/彼女はプロジェクトに失敗したはずですか？どうすればよいOOADになれますか？

26 design  object-oriented-design 

新しいウェブサイトでユーザー名を予約する必要があります。 これらは一般に3つのカテゴリに分類されます 1）誰も持ってはならないユーザー名（例：admin、user、service、help、rootなど） 2）彼らが現れるイベントで予約したい超有名人や会社の名前 3）当社が直接指定したその他の名前。 最初の2つのカテゴリのユーザー名のリストがどこかに存在し、それらを使用することができれば、本当に役立ちます。 誰もがそのようなリストを知っていますか？

26 database  design  data  api-design 

スクラムでデザインをどのように扱いますか？スクラムの繰り返しごとに十分に書かれた設計文書がまだありますか？UMLダイアグラムをフィーチャーした設計ノートを作成するだけですか？または、よくコメントされたコードがありますか？ 各イテレーションにはデザインの変更が含まれる場合があるため、新しい開発者がドメインを理解し、できるだけ早く参加できるようにするため、人々がこれをどのように捉えるかを知りたかっただけです。

26 design  scrum 

私が取り組んでいるプロジェクトは、複数のユーザー間でタスクリストを管理するWebアプリケーションを作成することです。これは、承認されたユーザーによってタスクアイテムが配布されるマスタータスクリストです。各ユーザーは、割り当てられたタスクにログインして表示するための独自のアカウントを持っています。複数のユーザーが単一のタスクを共有することは可能です。 次の状況を処理する方法の全体的な概念にさらに取り組んでいるので、プロジェクトの詳細をここから省こうとしていますが、それが役立つ場合は、RequestFactoryを実装したJava、EclipseLink、GWTを使用しています。データベースはPostgreSQLです。 したがって、私が調整しようとしている概念的な問題は次のとおりです。 複数のユーザーに共通の単一のタスクが何らかの方法で変更された場合（タスクの完了、削除など）、このタスクを持つすべてのユーザーのタスクリストが更新されます。この機能の実装を支援する設計パターンはありますか？ 私が調べたパターンには、ObserverとMediatorがあります。これらについて検討すべき他のパターンはありますか？ 2人のユーザーが同じタスクを同時に変更しているとします。 まず、そのような状況が発生するのを許可する必要がありますか、それとも誰かが変更を行うまでロックする必要がありますか？ 次に、ロックをかけない場合、どの変更を受け入れるかを調整するにはどうすればよいですか？これには、ユーザー1がデータを送信でき、ユーザー2が更新されたデータを受信する前に、先に進んで変更を送信した可能性があるため、1の状況が含まれます。 このWebアプリの複数のインスタンス間でデータを適切に同期する方法について提供できるガイドポイント、アドバイス、またはヒントを本当に探しています。とても感謝しています！

26 design  web-development  design-patterns  web-applications