YAGNI - Гибкая практика, которую нельзя называть?
Поскольку я все больше поглощал Agile-мышление в том, как я работаю, yagni ( "вам это не понадобится" ), кажется, становится все более и более важным. Мне кажется, что это один из самых эффективных правил для фильтрации ошибочных приоритетов и принятия решения о том, что не следует делать дальше.
Но ягни, похоже, представляет собой концепцию, которая едва слышится здесь в SO. Я выполнил обязательный поиск, и он появляется только в одном вопросе, а затем во вторичной роли.
Почему это? Я переоцениваю его важность?
Отказ от ответственности. Чтобы упредить ответы, я уверен, что буду возражать, позвольте мне подчеркнуть, что yagni является противоположным быстрому и грязному. Это побуждает вас сосредоточить свое драгоценное время и усилия на получении частей, в которых вы нуждаетесь.
Вот некоторые из текущих текущих вопросов, которые можно задать.
Являются ли мои тесты единиц выбранными на основе требований пользователя или структуры структуры?
Я устанавливаю (и тестирую и поддерживаю) тесты единиц, которые есть только там, потому что они выпадают из рамки?
Сколько из кода, сгенерированного моей каркасной структурой, я никогда не смотрел (но все равно могу укусить меня однажды, даже несмотря на yagni)?
Сколько времени я трачу на мои инструменты, а не на проблему пользователя?
При парном программировании значение роли наблюдателя часто находится в "yagni".
Используете ли вы инструмент CRUD? Позволяет ли вам (например, поощрять) использовать его как инструмент _RU_ или инструмент C__D, или вы создаете четыре фрагмента кода (плюс четыре модульных теста), когда вам нужен только один или два?
Ответы
Ответ 1
TDD в какой-то мере включил YAGNI. Если вы правильно выполняете TDD, то есть записываете только те тесты, которые приводят к необходимой функциональности, а затем разрабатывают простейший код для прохождения теста, а затем вы следуете принципу YAGNI по умолчанию. По моему опыту, это только тогда, когда я получаю нестандартно TDD и начать писать код, прежде чем тесты, тесты на то, что я на самом деле не нужно, или код, который является более чем простым способом, чтобы пройти тест, который я нарушу YAGNI.
По моему опыту последний является моим самым распространенным faux pas при выполнении TDD - я, как правило, продвигаюсь вперед и начинаю писать код для прохождения следующего теста. Это часто приводит к компрометации оставшихся тестов с использованием предвзятой идеи, основанной на моем коде, а не требований того, что нужно протестировать.
YMMV.
Ответ 2
Yagni и KISS (держите это просто, глупо) по сути являются одним и тем же принципом. К сожалению, я вижу, что KISS упоминается так часто, как я вижу "yagni".
В моей части пустыни наиболее распространенной причиной задержек и неудач проекта является плохое выполнение ненужных компонентов, поэтому я согласен с вашими основными настройками.
Ответ 3
Свобода изменения приводов YAGNI. В проекте водопада мантра - это область контроля. Сфера действия контролируется путем заключения контракта с клиентом. Следовательно, клиент наполняет все, что они могут придумать в документе о сфере видимости, зная, что изменения в области будут сложными после подписания контракта. В результате вы получаете приложения, в которых есть список функций, а не набор функций, которые имеют ценность.
С помощью гибкого проекта владелец продукта строит приоритетное отставание продукта. Команда разработчиков создает функции на основе приоритета, то есть значения. В результате в первую очередь создаются самые важные вещи. В итоге вы получаете приложение, которое имеет функции, которые оцениваются пользователями. Материал, который не важен, выпадает из списка или не выполняется. Это YAGNI.
В то время как YAGNI не является практикой, это результат списка приоритетов для отставания. Бизнес-партнер ценит гибкость, предоставляемую бизнесу, учитывая, что они могут изменять и переоценивать отставание продукта от итерации до итерации. Достаточно объяснить, что YAGNI - это преимущество, полученное, когда мы с готовностью принимаем изменения, даже в конце процесса.
Ответ 4
Проблема, которую я нахожу, заключается в том, что люди склонны вешать даже написание фабрик, используя контейнеры DI (если у вас уже есть это в вашей кодовой базе) под YAGNI. Я согласен с JB King там. Для многих людей, с которыми я работал с YAGNI, кажется, есть лицензия на сокращение углов/написание неаккуратного кода.
Например, я пишу API PinPad для абстрагирования PIN-кода нескольких моделей/производителей. Я обнаружил, что если у меня нет общей структуры, я не могу писать даже мои тесты. Может быть, я не очень опытный практик TDD. Я уверен, что будут разные мнения о том, что я сделал, это YAGNI или нет.
Ответ 5
Я видел много сообщений о SO, ссылающихся на преждевременную оптимизацию, которая является формой yagni или, по крайней мере, ydniy (вам она еще не нужна).
Ответ 6
Я не вижу YAGNI как противоположность быстро и грязно. Он делает то, что нужно, и не больше и не планирует, как программное обеспечение, которое кто-то пишет, должно длиться 50 лет. Это может произойти редко, потому что на самом деле не так много вопросов, чтобы спросить об этом, по крайней мере, на мой взгляд. Подобно "не повторяйте себя" и "соблюдайте простые, глупые" правила, которые становятся общими, но не обязательно анализируются и анализируются 101 способом. Некоторые вещи достаточно просты, что их обычно получают вскоре после небольшой практики. Некоторые вещи развиваются за кулисами, и если вы обернитесь и посмотрите, вы заметите, что это может быть другим способом заявить о себе.
