Почему так сложно применять YAGNI?
Я постоянно ломаю эту модель.
ЯГНИ - Тебе это не нужно
Я всего лишь младший разработчик, но я считаю, что даже разработчики старшего уровня делают то же самое.
"Ну, эта система может использовать его, и этот, так что давайте разработаем для него".
Иногда я ловлю себя, но чаще всего я выхожу из себя. Есть ли у кого-нибудь какие-либо советы для того, чтобы придерживаться YAGNI, или что-нибудь, что я могу сделать, чтобы лучше применять этот шаблон проектирования, пока я проектирую и кодирую?
15 ответов
Дизайн для чего-то
... полностью отличается от
Разработка чего-то.
Разработка чего-то означает, что вы разрабатываете свое приложение для будущего расширения на случай, если возникнет необходимость в написании кода (что хорошо... это означает, что вы делаете свое программное обеспечение расширяемым и простым в обслуживании).
Проектирование чего-либо означает, что вы пишете целое произведение сейчас... независимо от того, думаете ли вы, что кто-то на самом деле собирается его использовать или нет. Это не обязательно плохо, но это может быть огромной тратой времени.
Будьте осторожны с тем, что вы делаете.
Это как-то связано с перфекционизмом. давайте сделаем это идеально, давайте подготовим его для всех возможных будущих сценариев.
Это помогает быть прагматичным и трезвым, когда выбираешь шансы, которые ему понадобятся: заставь потом ответить либо "Да", либо "Нет". Может быть, нет.
Если нет явных доказательств, что это будет необходимо (это на повестке дня, об этом просил заказчик), и вы увидите, что лучше учитывать эту будущую функциональность в вашем текущем дизайне, оставьте это пока.
Просто используйте TDD!!!
редко вы обнаружите, что пишете тест для функции, которая вам не нужна...
Потому что ЯГНИ - это принцип, а не панацея
Разработка программного обеспечения всегда сводится к балансу многих требований. Дело не в том, чтобы понять что-то правильно, а в том, чтобы ошибаться. Один 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);
это простой контракт. Ото,
/// 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 вообще проектировали)
Дизайн не повредит
Появится ли Agile, "фаза дизайна" получила что-то дурное имя. Однако, чтобы быть хуже, чем вообще не планировать, ваши планы должны быть действительно катастрофическими. Самая большая опасность не в действительно плохих планах, а в попытках предвидеть каждую проблему и запрос на изменение. ЯГНИ бесценен здесь.
Они старшие, в конце концов, я их не знаю - их тенденция может быть связана с идеологической обработкой водопада старой школы и страхом перед переменами. Или, может быть, они старшие, потому что они знают свою работу - они узнали, какие части вы предпочитаете делать сейчас, а не позже, и какие части можно пожертвовать неуверенностью в будущем.
Привести в исполнение YAGNI так сложно, потому что я думаю, что большинство из нас укусила противоположная проблема - найти систему, которая слишком сложна или хрупка, чтобы ее можно было реорганизовать, чтобы делать то, что мы хотим, но которая могла бы сделать это с немного большей осторожностью., Найти середину может быть сложно.
Вообще говоря, если вы обнаружите, что думаете "может понадобиться [xyz]", то это должно явно сыграть роль в том, что вы кодируете. Даже если вы не пишете код для поддержки xyz, вы должны писать так, чтобы рефакторинг для добавления поддержки xyz был настолько практичным, насколько это возможно. Однако иногда это может означать создание чего-то более общего, чем это необходимо. Знание, где остановиться на этом пути - это, вероятно, то, что может сказать вам только информация, относящаяся к конкретной области, в сочетании с опытом.
"Назад к основам" и "Простое - это хорошо" - это пара фраз, которые напоминают мне о том, что нужно просто продолжать выполнять поставленную задачу и понять, почему я создаю эту функцию или усовершенствование, а не занимаюсь переподготовкой или планированием на миллион вещи, которые, вероятно, не произойдут. Где я работаю, мое имя часто используется как способ описать что-то слишком сложное или слишком сложное, например, "Вы знаете, как создать эту страницу". Я пытаюсь держать это под контролем, поскольку иногда это полезно, но не достаточно часто, чтобы это стало моей обычной практикой.
Иногда может помочь и требование, написанное в нетехнических терминах. Это позволяет мне знать, что я должен показать в конце, и не беспокоиться о более мелких деталях, например, пользователи системы вряд ли будут читать мой исходный код и высмеивать мое использование любого соглашения об именах, которое мы используем. Они заботятся о том, что это работает и делает то, что им нужно, и хотят, чтобы это делалось.
Другой вопрос, который нужно задать: "Они действительно просили об этом?" и попытаться свести к минимуму предположения о функциональности. Если его нет в списке, оставьте его, хотя спросите, хотят ли они этого.
Если вы создаете библиотеку / инструментарий / платформу / фреймворк, YAGNI приобретает другое значение.
Вы не можете быть уверены в том, как другие разработчики будут использовать ваш инструмент, и иногда имеет смысл более гибко проектировать, чтобы ваш продукт можно было использовать в более широком диапазоне сценариев. Прямая совместимость также является огромным фактором.
YAGNI по-прежнему применяется, но "оно" имеет тенденцию быть на уровне мета-функций, а не на уровне функций.
Ну, вчера я столкнулся с тем же, и сразился с одним из старших разработчиков. Я всегда стараюсь придумать что-то вроде "что если кто-то называет это, что если это изменит то-то и т. Д. И т. Д.?" и он другой край. "Просто сделай это и БЫСТРО!"
Ответ где-то между его подходом и моим. Как мы дойдем до середины? Между попыткой сделать "идеальный" дизайн, который люди будут ценить или НЕНАВИДЕТЬ, если им придется что-то менять в будущем.
ИМХО, ответ, по крайней мере при разработке модуля, сводится к базовым принципам объектно-ориентированного программирования, таким как определение понятных интерфейсов. Интерфейсы должны соответствовать требованиям заказчика. Основные интерфейсы для модуля не должны иметь ничего, что "решает" что-либо, кроме того, что есть в требовании. По крайней мере, некоторый уровень "наворотов" добавлен, потому что "что, если это изменится, им нужно это завтра и т. Д.", Можно удалить.
Все, что вы планируете поместить, потому что вы думаете, что это МОЖЕТ быть использовано завтра кем-то другим и т.д., должно обсуждаться часами! У вас должны быть веские причины для добавления "халявы" для кого-то, у кого в настоящее время даже нет имени!
Мне все еще нужен окончательный ответ на этот вопрос. Может быть, от какого-то архитектора, который разработал большие приложения и сталкивался с этой ситуацией 100 раз:)
YAGNI - это больше вопрос. Мы, как старшие разработчики, постоянно нарушаем YAGNI. Это действительно вопрос "необходимости". Тебе это нужно? Определите "необходимость". Я видел ужасные грязевые шары, созданные с помощью догмы ЯГНИ.
Не то чтобы я думаю, что ЯГНИ бесполезен... всегда стоит спросить: "Мне это нужно?"
Хорошо спроектировать свои приложения таким образом, чтобы упростить реализацию будущих функций, но на самом деле не следует реализовывать эти функции до тех пор, пока вам это не понадобится. Как это сделать, полностью зависит от проекта, над которым вы работаете.
Я нахожу рецензии и помощь в программировании. Еще один взгляд на ваши рассуждения быстро определит то, что вам нужно, но на самом деле это не так.
Напомните себе, что вы пытаетесь реализовать, и не делайте больше. Вы можете сделать это с
- четко написанные пользовательские истории / требования. Если "критерии приемлемости" для вашей работы четко изложены, легче судить, что-то входит или нет.
- кто-то (может быть, вы), который ожидает, что вы быстро закончите. Это заставляет вас убедиться, что вы не сбились с пути.
- TDD
- парное программирование или что-то близкое к нему
- ежедневные стоянки (или чаще), чтобы быть уверенным, что вы не уходите в сорняки
В нашей компании действует эмпирическое правило: когда мы обсуждаем разработку новой функции, первый вопрос, на который нужно ответить: "Кто на самом деле этого хочет?" если клиент стоит за этим, то мы пытаемся понять, чего он действительно хочет, и если есть другие способы решения его проблемы (вместо добавления новой функции). Если член команды запрашивает эту новую функцию, у него должны быть веские причины для этого. Среди них проблемы производительности и проблемы маркетинга, и мы снова пытаемся полностью понять запрос и обсудить все возможные альтернативы, прежде чем добавлять некоторые новые функции в нашу базу кода.
ЯГНИ часто бывает задним числом. Просто убедитесь, что вы достаточно проворны, чтобы удалить "Я", когда "ЯГНИ" становится очевидным.
Если вы следуете Agile, то вы можете работать над важными вещами, пока не доберетесь до вещей, которые вам не понадобятся. К тому времени, когда вы дойдете до вещей YAGNI, у вас уже будет довольно готовый продукт. Тогда дело за вами, чтобы сказать вам прекратить разработку вещей.