ЯГНИ - Гибкая практика, которую нельзя назвать? [закрыто]

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

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

Почему это? Я переоцениваю его важность?

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

Вот некоторые нерешенные текущие вопросы, которые можно задать.

Мои модульные тесты выбраны на основе требований пользователя или структуры фреймворка?

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

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

Сколько времени я трачу на работу над своими инструментами, а не над проблемой пользователя?

При парном программировании значение роли наблюдателя часто заключается в «ягни».

Вы используете инструмент CRUD? Позволяет ли он (нет, поощряет) использовать его как инструмент _RU_ или как инструмент C__D, или вы создаете четыре куска кода (плюс четыре модульных теста), когда вам нужен только один или два?

15.12.2008 22:23:04
Это не твоя вина, но я не могу выбросить Янни и его проклятые усы из головы.
MusiGenesis 15.12.2008 23:09:42
Вы должны были назвать это сообщение, Вы не Идете Назвать Это
sam 18.08.2015 14:59:52
6 ОТВЕТОВ
РЕШЕНИЕ

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

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

YMMV.

12
15.12.2008 22:32:37
Просто подумал, что упомяну, что укажу
Jason Baker 11.01.2009 20:49:44

Я видел много постов о SO, ссылающихся на преждевременную оптимизацию, которая является формой yagni или, по крайней мере, ydniy (она вам пока не нужна).

0
15.12.2008 23:07:06
Интересно, как ты это называешь, когда преждевременно оптимизируешь то, что тебе не нужно? :)
dkretz 15.12.2008 22:35:29
Le Dorfier: эпическая трата времени? (ewot): D
jalf 15.12.2008 23:05:37

Ягни и ПОЦЕЛУЙ (будь проще, глупый) по сути один и тот же принцип. К сожалению, я вижу, что KISS упоминается примерно так же часто, как и слова "ягни".

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

4
15.12.2008 22:46:04
Я тоже согласен с основным мнением о задержках проекта, но не согласен, что YAGNI и KISS - это одно и то же. Я видел много простого кода, который не нужен, и сложный код, который нужен.
Dour High Arch 17.05.2009 22:41:29
KISS действительно должен быть KIASAN (держите его настолько простым, насколько это необходимо). Простой ненужный компонент все еще более сложен, чем должен быть - нет ничего проще, чем ничего (NISTN?).
MusiGenesis 18.05.2009 15:11:22

Я не вижу YAGNI как противоположность быстрой и грязной, на самом деле. Он делает только то, что нужно и не более, и не планирует, как программное обеспечение, которое кто-то пишет, должно длиться 50 лет. Это может случиться редко, потому что на самом деле не так много вопросов, по крайней мере, на мой взгляд. Подобно правилам «не повторяйся» и «не усложняй, глупые», которые становятся общими, но не обязательно анализируются и анализируются 101 способом. Некоторые вещи настолько просты, что обычно их получают вскоре после небольшой практики. Некоторые вещи развиваются за кулисами, и если вы обернетесь и посмотрите, вы можете заметить, что они могут быть другим способом заявить о себе.

-1
17.12.2008 22:39:37
Вы упускаете суть. YAGNI, как и WATER (да, h2o), может быть плохим в избытке. Счетчик этого называется BDUF, или, если вам нужна аналогия, чтобы помочь вам в этом: Башня Слоновой Кости. Если ваш лидер (или кто-то еще) не стоит на башне из слоновой кости / участвует в BDUF, обнаруживая слабые места или неизвестных - у вас будут проблемы. Это не дает права ругать практику YAGNI, которая, по сути, является Agile.
gogogadgetinternet 21.02.2014 09:24:58

Проблема, которую я нахожу, состоит в том, что люди склонны создавать даже фабрики, используя DI-контейнеры (если у вас их нет в базе кода) под YAGNI. Я согласен с JB King там. Для многих людей, с которыми я работал, YAGNI кажется лицензией на то, чтобы срезать углы / писать неаккуратный код.

Например, я писал API-интерфейс PinPad для абстрагирования PINPad для нескольких моделей / производителей. Я обнаружил, что если у меня нет общей структуры, я не могу написать даже свои юнит-тесты. Может быть, я не очень опытный практик TDD. Я уверен, что будут разные мнения о том, что я сделал, ЯГНИ или нет.

1
17.12.2008 23:16:58
Заводской спам заставляет меня гадить. Зачастую все, что нужно, - это функция более высокого порядка, служащая фабрике. И даже более часто, ни одного завода не требуется вообще, но это золотой молот , который легко понять.
dss539 3.06.2009 17:09:09
Смотрите мой ответ на JB King ниже. Я не думаю, что вы понимаете ЯГНИ.
gogogadgetinternet 21.02.2014 09:26:41

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

В гибком проекте владелец продукта создает приоритетное резервирование продукта. Команда разработчиков строит функции на основе приоритета, т.е. стоимости. В результате самые важные вещи создаются в первую очередь. В итоге вы получите приложение, которое имеет функции, которые ценятся пользователями. То, что не важно, выпадает из списка или не выполняется. Это ЯГНИ.

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

3
17.05.2009 22:13:28