4

私は友人と別の口論をしています。

当事者間である種のイベント (メッセージ) を送信するために基本的に使用される単純な JSON ベースのプロトコルを設計する必要があると考えてください。

言って、何か

 { event_id: 1, chat_message: "Hello" }
 { event_id: 2, group_id: 3, presence: "online" }
 ...

私はこのプロトコルを上記のように維持することを提案しますが、私の友人は次のようなことを提案しています:

 { event_id: 1, details: { chat_message: "Hello" } }
 { event_id: 2, group_id: 3, details: {  presence: "online" } }
 ...

彼の主張は、TCP と HTTP が「責任」の異なる層にあるように、このプロトコルはデータを分離しておくために「詳細」サブオブジェクトを使用する必要があるというものです。

彼が持っているもう 1 つの議論は、一致したイベントを処理するハンドラーは、"ルーティング" 情報 (event_id など) について何も認識してはならないというものです。

私の主張は次のとおりです。

  1. この情報をハンドラーから隠すために、各メッセージ (およびネットワーク トラフィック。これは、大量のメッセージを交換するシステムにとって重要な場合があります) の長さを増やしています。

  2. ハンドラーは、適切に応答するために、実際には「ルーティング」情報を知る必要があります。

    this.replyTo(event['event_id'], reply); // or...
this.replyTo(event, reply);

  3. event_id などをハンドラーから隠す必要がある場合でも、ハンドラーに渡す前にそれらを取り除くだけで、トラフィックを節約できます。

このプロトコルは非常に単純で、他の人が使用することは想定されていません。

どう思いますか？

4

4 に答える 4

4

大きな プロジェクト で の 長い 経験 の 後 , 私 はガホアとチャーリー マーティンに 強く 反対 し なけれ ば なり ませ ん .の提案。アジャイルと古典的なアプローチの間には大きな緊張があります。彼らの提案はアジャイルに見えるかもしれませんが、私は同意できません。何かを設計する場合は、今でも間違っているとわかっている方法で設計しないでください。それはアジャイルではなく、ばかげています。あなたの要件が将来も変わらないと思っているとは信じられないので、ドアを開いたままにして、リファクタリングの影響を最小限に抑えてください。現在の設計では、イベント タイプ ディスパッチャー -> グループへのルーター -> 最終的なイベント ハンドラー/ストレージなど、さまざまなサブシステムによってイベントが処理される場合、相互への影響を最小限に抑えて各サブシステムの変更を維持します。私にとって最善の方法は、タマネギの皮のつぼみのような設計プロトコルです。現在の要件以外の細部まで設計しないでください。アジャイルです。

あなたの引数：

広告 1. 時期尚早の最適化です。本当にトラフィックを最小限に抑える必要がある場合は、代わりにバイナリ プロトコルを使用してください。

広告 2. プロトコル自体ではなく、内部プログラムのインストルメンテーションで機能します。特に Erlang では間違った設計です。ハンドラーは宛先に直接戻るのではなく、ソケットの所有権などを保持するルーター (通常はディスパッチャーに戻る) に戻る必要があります。時期尚早の最適化のようです。

広告 3. 私は反対のアプローチを好みます。サブシステムに最小限のデータセットを提供して、副作用を最小限に抑え、(単体) テストを簡素化し、2. ポイントからのアプローチを使用する誘惑を回避します。必要に応じて延長します。逆にしないでください。

PS: なぜイベントに名前を付けずに ID を使用するのですか? また時期尚早の最適化？

編集: ID が明確化されました。これらはイベント番号ですが、イベント クラスではありません。別のクラス キーがあるはずです。

于 2009-02-20T10:26:45.183 に答える
2

かつて、ARPAnetがまだ新しく、IPがまだアイデアの芽であったとき、誰かが「ああ、そうだね、32ビットIPアドレスは十分だ-40億アドレス？誰もそれを必要としないだろう。地獄、私たちはそれらを異なるアドレスタイプに分割することができ、十分な余地があります。」

25年後、それが問題になることを私たちはほとんど知りませんでした。

また、ドメインの命名についても私に話さないでください。

重要なのはこれです：あなたは何が変わることができるかについて考える必要があります。エレガンスのためだけにこれを名前空間の階層にすることは不要で無駄です。余分なレイヤーがそれ以上の情報コンテンツを提供しない場合は、なぜ面倒なのですか。

一方、問題の変更に対するコードの感度を下げるため、または実装を著しく簡単にしたり、エラーが発生しにくくしたりするためにそれを行っている場合は、それだけの価値があるかもしれません。

それであなたの答えがあります：それはただもっとエレガントであるということですか、それとも他の利点がありますか？

于 2009-02-20T02:55:52.410 に答える
2

シンプルさを優先...

仕様、分散システム、および制御できないさまざまな状況で使用される仕様を作成する場合は、適切性が必要になります。

語用論的であるため、「言語の力」を使用して、それぞれの場合を処理するコードを書く方がよい場合がよくあります。必要がない限り、抽象化しないでください。

単純にする。早くしてください。清潔に保ちます。

何に進化する必要があるか（機能またはパフォーマンス）がわからないため、抽象化が進むほど、リファクタリングが難しくなります。

于 2009-02-20T02:48:17.233 に答える
0

これらは 2 つの正しい解決策です。本当にネットワーク トラフィックを心配する必要がある場合、ソリューションは受け入れられます。ただし、コードのメンテナンスはコードの寿命の大部分を占めることも覚えておく必要があります。そのため、今日コードをきれいにすることで、おそらく将来の時間を節約できます (メンテナンスについては既に述べました)。

私の意見では、この種の最適化について考えるには、強力な事実に基づいた適切な議論が必要です。

于 2009-03-08T09:30:12.393 に答える