Почему настолько трудно осуществить YAGNI? [закрытый]

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

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

ЯГНИ часто бывает задним числом. Просто убедитесь, что вы достаточно проворны, чтобы убрать «я», когда «ЯГНИ» станет очевидным.

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

Ну, вчера я столкнулся с тем же самым и сильно поссорился с одним из старших разработчиков. Я всегда стараюсь проектировать, используя "что, если КТО-ТО это назовет, что, если это изменит томм и т. Д.?" а он - другая крайность. «Просто заставь это работать и БЫСТРО!»

Ответ находится где-то посередине между его подходом и моим. Как нам найти золотую середину? Между попытками создать «идеальный» дизайн, который люди будут ценить или ненавидеть, если им придется что-то менять в будущем.

ИМХО, ответ, по крайней мере, при разработке модуля, сводится к основным принципам объектно-ориентированного программирования, таким как определение четких интерфейсов. Интерфейсы должны соответствовать требованиям заказчика. В основных интерфейсах модуля не должно быть ничего, что «решает» что-либо, кроме того, что указано в требовании. По крайней мере, некоторый уровень «излишеств», добавленных из-за того, что «что, если это изменится, им понадобится это завтра и т. Д.» Можно удалить.

Все, что вы планируете добавить, потому что вы думаете, что это МОЖЕТ быть использовано завтра кем-то другим и т. нужно обсуждать часами! У вас должны быть веские причины для добавления «халявы» для КТО-ТО, у кого в настоящее время даже нет имени!

Мне все еще нужен окончательный ответ на этот вопрос. Может быть, от какого-нибудь архитектора, который проектировал большие приложения и 100 раз сталкивался с этой ситуацией :)

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

Remind yourself what you are trying to implement, and don't do more. You can do this with

• clearly written user stories/requirements. If the "acceptance criteria" for your work is clearly outlined, it's easier to judge whether something is in or out.
• someone (maybe yourself) who expects you to complete things rapidly. This forces you to make sure you're not going off track.
• TDD
• pair programming, or something close to it
• daily stand-ups (or more frequent), to make sure you're not going off into the weeds

ЯГНИ - это действительно вопрос, который нужно задать. Мы, как старшие разработчики, постоянно нарушаем YAGNI. Это действительно вопрос «потребности». Тебе это нужно? Определите «потребность». Я видел ужасные комья грязи, образовавшиеся с использованием догмы ЯГНИ.

Не то, чтобы я думаю, что ЯГНИ бесполезен ... всегда стоит спрашивать: «Нужно ли мне это?»

"Back to basics" and "Simple is good" are a couple of phrases that pop up to remind me to just stay on the task at hand and realize why am I building this feature or enhancement and not get into overengineering or planning for a million things that probably won't happen. Where I work my name is often used as a way to describe something overengineered or overly complex,e.g. "You JBed how to build that page." I am attempting to keep this in check more as sometimes it is useful but not often enough for it to become my common practice.

Having a requirement written out in non-technical terms can sometimes help too. This lets me know what I have to show at the end and not worry about the finer details, e.g. the users of the system aren't likely to read over my source code and mock my use of whatever naming convention we use. They care that it works and does what they need and want it to do.

Another question to ask is, "Did they really ask for this?" and try to minimize assumptions one makes about functionality. If it isn't in the list, then leave it out, though ask if they want it.

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

В общем, если вы поймете, что думаете: «Возможно, потребуется [xyz]», то это должно явно сыграть роль в том, что вы кодируете. Даже если вы не кодируете поддержку xyz, вы должны кодировать таким образом, чтобы рефакторинг для добавления поддержки xyz был настолько практичным, насколько это возможно. Однако иногда это может означать создание чего-то более общего, чем это необходимо. Знать, где остановиться на этом пути, вероятно, может вам только информация о предметной области в сочетании с опытом.

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

Это помогает быть прагматичным и трезвым при определении вероятности того, что это будет необходимо: заставьте, а затем ответьте либо «Да», либо «Нет». Может быть, нет.

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

Просто используйте TDD !!!

редко вы будете писать тест для функции, которая вам не нужна ...

Если вы создаете библиотеку / инструментарий / платформу / фреймворк, YAGNI приобретает другое значение.

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

YAGNI по-прежнему применяется, но «это» имеет тенденцию быть на уровне мета-функций, а не на уровне функций.

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

В этом смысле YAGNI поможет избежать следующих ловушек:

• Когда вам нужен компилятор, создайте компилятор, а не самокомпилирующийся компилятор. фреймворк (Наша сила - решение общей проблемы - также наша слабость)
• Не недооценивайте усилия по реализации.
• Не переоценивайте время жизни вашего приложения и стабильность требований

Трудно сбалансировать конкурирующие требования. Но именно поэтому, как язвительно заявил МакКоннелл, разработка программного обеспечения - это инженерия.

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

Один пример (возможно, не очень удачный):

/// Estimates the time required to comlete the batch.
/// If the time cannot be estimated reliably, the return value is -1
/// \returns [double] estimated time in seconds
double EstimateDuration(Batch & batch);

- простой контракт. OTOH,

/// Estimates the time required to comlete the batch.
/// If the time cannot be estimated reliably, the return value is -1.
/// This function does not support looping batches (right now, looping
/// batches only run under a servicve account with no UI, so it's not needed).
/// Also, when the moon is full, the return value is -1, but an estimate 
/// is found in batch.JeffsEstimate. This value is used only by Jeff's core 
/// build script which runs roughly once a month.
/// \returns [double] estimated time in seconds
double EstimateDuration(Batch & batch);

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

Дизайн не повредит
Будет ли приход гибкости, «фаза проектирования» "получил плохую репутацию. Однако, что хуже, чем полное отсутствие планирования, ваши планы действительно должны быть катастрофическими. Самая большая опасность - это не по-настоящему плохие планы, а попытка предвидеть каждую проблему и запрос на изменение. ЯГНИ здесь бесценен.

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