Как далеко вы с YAGNI?

Ответ 1

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

Некоторые вещи, которые вам понадобятся. С моей точки зрения, два наиболее важных момента:

• Не стреляйте в ногу, не готовя приложение к интернационализации. Если ваше приложение будет хорошим, интернационализация будет стоять на столе один день. Кроме того, способность обрабатывать иностранные символы с использованием UTF-8 является абсолютным требованием при создании приложения с нуля в 2010 году. Интернационализация может показаться не такой важной для английского языка носителем языка, но, поверьте, это важно и боль интернационализации приложение позже ужасно.

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

Ответ 2

Это то, что они называют "прототипированием". Пойдите для этого.

Там тонкость между YAGNI и прототипированием.

• Когда пользователь запросил фейтурит, и вы говорите "нет", что YAGNI.

• Когда выполняется реализация (I18N, "развязка" (?), очереди, тайники, таймеры и т.д.), и вы говорите "нет" себе. Это не правда YAGNI. Это прототипирование.

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

Ответ 3

YAGNI напоминает вам о различии между тем, что вы можете сделать, и тем, что вам нужно сделать, чтобы удовлетворить ваши требования.

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

Ваше веб-приложение может поддерживать OpenID, Active Directory, Local Database, Flat File и другие методы проверки подлинности, но вы можете удовлетворить это требование, выполнив самый простой. (Для меня YAGNI подразумевает DTSTTCPW).

"Я могу сделать что угодно, учитывая достаточно времени"

- Каждый программист, которого я когда-либо встречал

Ответ 4

Я не поклонник принципа YAGNI; Я вижу, что он слишком часто используется в обосновании плохо разработанного программного обеспечения. Конечно, слишком продуманное программное обеспечение также является проблемой, но "YAGNI" на самом деле не оставляет много места для фактического анализа воздействия.

Оказывается, что в мире программного обеспечения многие из тех вещей, которые, по вашему мнению, вам не понадобятся, на самом деле вам понадобятся. А потом некоторые. Who'dathunkit.

Я написал одно или два приложения, которые должны были быть отложенными приложениями или холдингами, которые все еще находятся в производстве через два года. Они больно поддерживать.

Особенно, когда речь идет о безопасности, возможно, вам это понадобится.

Ответ 5

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

Ответ 6

Если вы действительно разработаете революционное веб-приложение для корпоративного рынка, я не уверен, какая из этих вещей Y ou A int G onna N eed.

Также ваши примеры довольно специфичны. Например, когда вы говорите: "никаких функций безопасности"... Я бы сказал, что пользователи - это одна вещь, с которой вы, возможно, можете обойтись, но дезинфекция ваших входов - это то, что вы не можете. Кроме того, "масштабируемость" - это не вопрос о чередовании или репликации базы данных, это решения, которые вы принимаете после того, как осознаете, что ваше приложение недостаточно масштабируется.

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

Просто мой 0.2

Ответ 7

Если вы возьмете "ЯГНИ" до такой крайности (и я обойдусь дискуссиями о том, действительно ли это хорошая идея, а также дискуссии о том, действительно ли это "ЯГНИ" ), вы должны быть готовы беспощадно реорганизовать свои codebase, чтобы добавить позже, что вы сейчас уходите, не создавая Ball of Mud.

Ответ 8

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

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

Что касается масштабируемости, очередей, кеширования: это зависит. Каково требование для приложения? Это сайт интрасети, используемый 10 одновременными пользователями или популярный веб-сайт с миллионами пользователей. Это зависит. Найдите требования и сделайте это - ничего больше. YAGNI. Если ваше требование изменится; измените ваше приложение - оно должно быть открытым для внесения изменений.

Ответ 9

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

Ответ 10

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

Здесь одна область, где я чувствую, что некоторые сторонники YAGNI могут пойти далеко: если вам нравится OOD/полиморфизм, обычно вам очень мало "испечь" некоторые большие точки расширения для будущего использования, даже в прототипе.

Вот пример...

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

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

Ответ 11

Я бы сказал, что если вы начинаете с того, что выбрасываете весь здравый смысл и выполняете весь проект наиболее целесообразным способом, то то, что вы получите в итоге, - это большая куча неудач... Что нет означает Революционный (tm).

Если вы действительно хотите знать, будет ли это полезно, выполните некоторые макеты экрана. Может быть, даже обычный обычный жесткий код html. Отнесите их потенциальным клиентам и посмотрите, не можете ли вы попасть в дверь. Если некоторые из них начнут кусаться, то бюст ваш прикладом и построить его.

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

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

Ответ 12

Что бы я сделал:

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

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

3). Затем вы можете сосредоточиться на функциях, которые сделают ваше приложение летающим и более важным для ваших потенциальных клиентов.

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

Ответ 13

По-моему, за YAGNI следует по умолчанию, поскольку он позволяет значительно повысить производительность.

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

Ответ 14

Да, НО...

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

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

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

(К сожалению, аргумент применяется только в том случае, если вы знаете веб-рамки уже. Знание царит в царстве ЯГНИ.)