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

Question

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

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

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

Отказ от ответственности.Чтобы упредить ответы, я уверен, что получу возражения, позвольте мне подчеркнуть, что ягни – это противоположность быстрому и грязному.Это побуждает вас сосредоточить свое драгоценное время и усилия на получении правильных деталей, которые вам ДЕЙСТВИТЕЛЬНО нужны.

Вот несколько нестандартных вопросов, которые можно задать.

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

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

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

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

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

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

Answer 1

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

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

ЮММВ.

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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