Простота протокола в сравнении с «собственностью»

Question

У меня есть другой аргумент с моим другом.

Рассмотрите необходимость создания упрощенного протокола на основе 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 находятся на разных уровнях «ответственности», этот протокол должен использовать под-объект «детали», чтобы сохранить разделенные данные.

Еще один аргумент, который он имеет, заключается в том, что обработчики, которые обрабатывают согласованное событие, не должны знать ничего о «маршрутизации» информации (например, event_id).

Мои аргументы:

1. Мы увеличивая длину каждого сообщения (и сетевого трафика, это может быть важно для системы, которая обменивается с большим количеством сообщений) ради сокрытия этой информации от обработчики

2. обработчики сделать на самом деле нужно знать «маршрутизация» информация, скажем, ответить на них должным образом:

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

3. Даже если нужно скрыть event_id и вещи л икэ что из обработчиков, мы можем просто лишить их, прежде чем перейти к обработчикам и при этом еще сэкономить на трафике

Этот протокол достаточно прост и не должен использоваться кем-то другим.

Что вы думаете вы?

Answer 1

Фавор простота ...

собствен будут необходимы, когда вы пишете спецификацию, распределенную систему, и один, который будет использоваться во многих различных обстоятельствах вне вашего контроля.

Будучи Pragmatic, часто лучше использовать «силу языка» и просто писать код для обработки каждого случая. Не аннотация если вы не необходимо.

Сохраните это. Держите это быстро. Держи в чистоте.

Вы не знаете, в чем он может нуждаться, чтобы развиться (функции или производительность), и чем больше у вас будет абстракции, тем сложнее будет повторить фактор.

Answer 2

Когда-то, когда ARPAnet все еще была новой, а IP все еще был зародышем идеи, кто-то сказал: «О, ну, 32-битный IP-адрес - много млрд. адресов? нужно, черт возьми, мы можем разделить их на разные типы адресов, есть много места... "

Мало ли мы знаем, 25 лет спустя, что это будет проблемой

И даже не говорить мне о наименовании домена

Дело заключается в следующем: вам нужно думать о том, что может измениться. Создание этого в иерархии пространств имен просто ради элегантности в является ненужным и расточительным, и когда ваш дополнительный слой не дает больше информативности, то зачем.

на с другой стороны, если вы делаете чтобы сделать ваш код менее чувствительным к изменениям в проблеме или сделать реализацию заметно проще или менее подверженной ошибкам, тогда это может стоить того.

Итак, есть ваш ответ: это только, чтобы быть более изящным или у него есть другие преимущества?

Answer 3

После долгого опыта работы в большом проекте я не могу не согласиться с предложениями gahooa и Charlie Martin. Между гибким и классическим подходом существует большая напряженность. Их предложения могут показаться подвижными, но я не могу согласиться. Если вы что-то создаете, никогда не разрабатывайте его так, как вы знаете, это неправильно даже сейчас. Это не круто, это глупо. Я не могу поверить, что вы думаете, что ваши требования не изменятся в будущем, так что держите двери открытыми, а рефакторинг - минимальными. Когда в вашем текущем событии проектирования обрабатываются разные подсистемы как диспетчер типа событий -> маршрутизатор для группировки -> обработчик/хранение конечных событий или что-то еще, сохраняйте изменения в каждой подсистеме с минимальным воздействием друг на друга. Лучше всего для меня это протокол разработки, такой как луковый пилинг, не дизайн его для каждой тонкой детали за пределами ваших текущих требований. Это проворно.

вы аргументы:

объявлений 1. Это преждевременная оптимизация. Если вам действительно нужно минимизировать трафик, вместо этого используйте двоичный протокол ;-) Другой способ издержки/выгоды от ti неправильный.

ad 2. Это работа для внутренней программной аппаратуры, а не для самого протокола. Это неправильный дизайн, особенно в Эрланге. Ваш обработчик не должен возвращаться непосредственно к месту назначения, а к некоторому маршрутизатору (обычно обратно к диспетчеру), который сохраняет принадлежность сокета и тому подобное. Похоже, преждевременная оптимизация!

ad 3. Я предпочитаю противоположный подход. Предоставьте минимальный набор данных для подсистем, чтобы минимизировать побочные эффекты, упростить (единичное) тестирование и избежать соблазнения, чтобы использовать подход с 2. точки. При необходимости расширьте. Не делайте этого наоборот.

P.S .: Почему вы не называете свое мероприятие, но используете идентификаторы? Преждевременная оптимизация снова?

Редактировать: Идентификаторы уточняются, это номера событий, но не классы событий. Должен быть другой ключ класса.

Answer 4

Это . Если вам действительно нужно беспокоиться о сетевом трафике, ваше решение приемлемо. Но вы также должны помнить, что обслуживание кода занимает большую часть срока службы кода, поэтому, делая очиститель кода сегодня, вы, вероятно, сэкономите некоторое время в будущем (уже упомянутое обслуживание).

На мой взгляд, у вас должны быть хорошие аргументы, основанные на сильных фактах, чтобы подумать о таких оптимизациях.