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

Принцип YAGNI "гласит, что вам не следует сосредотачиваться на предоставлении функциональности до того, как вам понадобится, поскольку" вам это не понадобится ".

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

ИМХО

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

Конструирование части протокола позже часто приводит к таким мыслям, как "Черт, я должен был сделать это таким образом, теперь я должен использовать это уродливое обходное решение"

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

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

Ответ 8

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

Вот несколько:

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

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

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