Когда нарушать ЯГНИ?
"Принцип" YAGNI гласит, что вы не должны фокусироваться на предоставлении функциональности до того, как вам это понадобится, поскольку "вам это все равно не понадобится".
Я обычно склонен использовать здравый смысл над любым правилом, несмотря ни на что, но бывают случаи, когда я чувствую, что это полезно для чрезмерного проектирования или доказательства будущего, если у вас есть веские причины, даже если возможно, что вы никогда не будете его использовать.
Фактический случай, который я сейчас держу в руках, примерно так:
У меня есть приложение, которое должно работать по простому проприетарному протоколу связи (уровень 4 OSI). Этот протокол имеет желательный набор характеристик (например, следуя спецификации NORM), которые обеспечивают устойчивость приложения, но не являются строго обязательными (многоадресная рассылка UDP может работать приемлемо).
Существует также тот факт, что приложение, вероятно, (но не обязательно) будет использоваться другими клиентами в будущем, которые не будут иметь доступа к проприетарному решению и, следовательно, будут нуждаться в другом решении. Я точно знаю, что вероятность другого клиента для приложения высока.
Итак, что ты думаешь? Должен ли я просто разрабатывать собственный протокол и оставить рефакторинг, извлечение интерфейса и т. Д. До момента, когда он мне действительно понадобится, или я должен проектировать сейчас, думая о (не очень) будущем?
Примечание: просто чтобы прояснить, мне интересно выслушать всевозможные мнения по общему вопросу (когда нарушать YAGNI), но мне бы очень хотелось получить несколько советов или мыслей по поводу моей нынешней дилеммы:)
8 ответов
По моему мнению
- Я бы сказал, иди ЯГНИ первым. Получите это без спецификации NORM, используя " простейшую вещь, которая будет работать ".
- Затем сравните, если стоимость внесения "проектных изменений" в будущем значительно выше, чем внесение изменений сейчас. Является ли ваше текущее решение обратимым? Если вы можете легко внести изменения завтра или через пару месяцев, не делайте этого сейчас. Если вам не нужно принимать необратимое проектное решение сейчас... откладывайте до последнего ответственного момента (чтобы у вас было больше информации, чтобы принять лучшее решение)
Закрытие, если вы знаете со значительной степенью уверенности, что что-то на горизонте, и добавление этого позже будет болезненным, не будьте страусом... дизайн для этого.
например, я знаю, что диагностические журналы будут необходимы до поставки продукта. Добавление кода регистрации через месяц было бы намного сложнее, чем добавление его сегодня, когда я пишу каждую функцию... так что в этом случае я бы переопределил YAGNI, даже если мне сейчас не нужны журналы.
См. Также: книги Lean T. & M. Poppendieck лучше объясняют дилемму пули № 2 выше.
Причина, по которой YAGNI относится к коду, заключается в том, что стоимость изменений низкая. С хорошим, хорошо переработанным кодом добавление функции позже обычно обходится дешево. Это отличается от, скажем, строительства.
В случае протоколов, добавление изменений позже обычно не дешево. Старые версии ломаются, это может привести к сбоям связи, а также к матрице тестирования N^2, так как вы должны проверять каждую версию на соответствие любой другой версии. Сравните это с отдельными кодами, где новые версии должны работать только с собой.
Так что в вашем случае для разработки протокола я бы не рекомендовал YAGNI.
Правильное структурирование вашей программы (абстракция и т. Д.) - это не то, к чему относится YAGNI. Вы всегда хотите хорошо структурировать свой код.
Просто чтобы прояснить, я думаю, что ваше текущее затруднение связано с чрезмерным применением YAGNI. Структурирование вашего кода таким образом, чтобы у вас была многократно используемая библиотека для использования этого протокола, является просто хорошей практикой программирования. ЯГНИ не применяется.
Я думаю, что это довольно просто и очевидно:
Нарушайте ЯГНИ, когда знаете, что в полной уверенности вам это понадобится
Я думаю, что YAGNI может быть неуместным, если вы хотите чему-то научиться:) YAGNI полезен для профессионалов, но не для студентов. Когда вы хотите учиться, вам это всегда нужно.
Я бы не волновался. Тот факт, что вы знаете о "ЯГНИ", означает, что вы уже мыслите прагматично.
Я бы сказал, что независимо от того, что здесь опубликовано, у вас статистически больше шансов придумать лучший код, чем у тех, кто не анализирует свои методы подобным образом.
Я согласен с Гишу и Ником.
Разработка части протокола позже часто приводит к мысли вроде: "Черт, я должен был сделать это таким образом, теперь я должен использовать этот уродливый обходной путь"
Но это также зависит от того, кто будет взаимодействовать с этим протоколом.
Если ваш контроль завершается, и что они изменят версию одновременно, вы всегда можете рефакторинг протокола позже, как с обычным интерфейсом кода.
Что касается реализации дополнительных функций протокола позже, я обнаружил, что реализация протокола очень помогает в проверке его дизайна, так что вы можете, по крайней мере, захотеть сделать простой пример кода для тестирования, если вам нужен дизайн для быть официальным
В некоторых случаях имеет смысл идти против интуиции YAGNI.
Вот несколько из них:
Следующие соглашения программирования. Особенно базовый класс и интерфейсные контракты. Например, если базовый класс, который вы наследуете, предоставляет GetHashCode и метод Equals, переопределение Equals, но не GetHashCode, нарушает документированные платформой правила, которым разработчики должны следовать, когда они переопределяют Equals. Это соглашение должно соблюдаться, даже если вы обнаружите, что GetHashCode на самом деле не вызывается. Не переопределять GetHashCode - это ошибка, даже если в настоящее время нет способа ее спровоцировать (кроме надуманного теста). В будущей версии платформы могут появиться вызовы GetHashCode. Или другой программист, который изучил документацию (в данном примере документацию платформы для базового класса, который вы наследуете), может по праву ожидать, что ваш код придерживается без проверки вашего кода. Другой способ думать об этом заключается в том, что весь код и соответствующая документация должны быть согласованными, даже с документацией, написанной другими, например, предоставленной поставщиком платформы.
Поддержка настройки. Особенно сторонними разработчиками, которые не будут изменять ваш исходный код. Вы должны выяснить и реализовать подходящие точки расширения в своем коде, чтобы эти разработчики могли реализовать все виды функциональных возможностей дополнений, которые никогда не приходили вам в голову. К сожалению, вполне естественно, что вы добавите некоторые расширяемые функции, которые в конечном итоге будут использовать лишь немногие внешние разработчики. (Если можно заранее обсудить требования к расширяемости со всеми внешними разработчиками или использовать частые циклы разработки / выпуска, это прекрасно, но это не выполнимо для всех проектов.)
Утверждения, проверки отладки, сбои и т. Д. Такой код на самом деле не нужен для правильной работы вашего приложения, но он поможет убедиться, что ваш код работает правильно сейчас и в будущем, когда будут внесены изменения.