Протокол простота против "правильности"

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

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

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

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

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

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

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

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

Answer 2

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

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

И даже не говорите со мной об именах доменов.

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

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

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

Answer 3

Благосклонность простота ...

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

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

Будьте проще. Держи это быстро. Держите его в чистоте.

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

Answer 4

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

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