Когда нужно нарушать ЯГНИ?

Question

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

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

Фактический случай у меня есть в моих руках прямо сейчас, более или менее, как это:

У меня есть приложение, которое должно работать над простой собственный протокол связи (уровень OSI 4). Этот протокол имеет желаемый набор характеристик (например, следующую спецификацию NORM), которые обеспечивают надежность приложения, но которые не являются строго обязательными (многоадресная рассылка UDP может выполнять приемлемую).

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

Итак, что вы думаете? Должен ли я просто разрабатывать проприетарный протокол и оставлять рефакторинг, извлечение интерфейса и т. Д., Когда мне это действительно нужно, или мне должно быть сейчас думать о будущем (пока)?

Примечание: Просто чтобы быть ясно, я заинтересован услышать все виды мнений к общему вопросу (если нарушать YAGNI), но я бы очень хотел, некоторые советы и мысли о моей нынешней дилемме :)

Answer 1

ИМХО

• Я бы сказал, что идти YAGNI первым. Получите его работу без спецификации NORM, используя «простейшая вещь, которая будет работать».
• Следующее сравнение, если стоимость внесения «изменений дизайна» в будущем будет значительно больше, чем внести изменения сейчас. Ваше текущее решение reversible? Если вы можете легко внести изменения завтра или через пару месяцев, не делайте этого сейчас. Если вам не нужно принимать необратимое дизайнерское решение сейчас.задержка до последнего ответственного момента (так что у вас есть больше информации, чтобы сделать лучшее решение)

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

См. Также: T. & Положительные книги М. Поппендика лучше объясняют дилемму пули № 2 выше.

Answer 2

Я думаю, что YAGNI может быть неуместным, если вы хотите чему-то научиться :) YAGNI хорош для профессионалов, но не для студентов. Когда вы хотите учиться, вам это всегда понадобится.

Answer 3

Я бы не стал беспокоиться. Тот факт, что вы знаете о «ЯГНИ», означает, что вы уже мыслите прагматично.

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

Answer 4

Структурирование вашей программы хорошо (абстракция и т. Д.) Не относится к YAGNI. Вы всегда хотите хорошо структурировать свой код.

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

Answer 5

Я думаю, что это довольно просто и очевидно:

Нарушать YAGNI, когда вы знаете, что, в полной уверенности, Вы собираетесь нуждаться в этом

Answer 6

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

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

Так что в вашем случае для дизайна протокола я бы не рекомендовал YAGNI.

Answer 7

Я согласен с Гишу и Ником.

Проектирование часть протокола позже часто приводит к мысли как «черт, я бы это именно так сделано, теперь я должен использовать этот уродливый обходной путь»

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

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

Answer 8

Есть некоторые случаи, когда имеет смысл идти против интуиции YAGNI.

Вот некоторые из них:

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

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

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