Как далеко вы зашли с ЯГНИ?[закрыто]

Question

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

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

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

• Никакой интернационализации.Просто английская строка, встроенная в исходный код.

• Никакой развязки.Просто веб-страницы, которые взаимодействуют с базой данных.

• Никаких исполнительских трюков.Никаких очередей, кэшей, таймеров, фоновых заданий, асинхронных вызовов и т.д.

• Нет масштабируемости.Никакого разбиения базы данных на разделы, никаких сегментов, никакой кластеризации или репликации.

• Кроме того, при необходимости используйте YAGNI на микроуровне.

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

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

Это то, что люди подразумевают под ЯГНИ, или это патологический и преувеличенный пример ЯГНИ?

Answer 1

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

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

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

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

Answer 2

Это то, что они называют «прототипированием».Действуй.

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

1. Когда пользователь запрашивает функцию, а вы говорите «нет», это YAGNI.

2. Когда это реализация (I18N, "развязка"(?), очереди, кэши, таймеры и т.д.) и ты говоришь себе нет.Это не совсем ЯГНИ.Это прототипирование.

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

Answer 3

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

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

Ваше веб-приложение может поддерживают OpenID, Active Directory, локальную базу данных, неструктурированный файл и множество других методов аутентификации, но вы можете удовлетворить это требование, реализовав самый простой из них.(Мне, ЯГНИ подразумевает DTSTTCPW).

«Я могу сделать все, если у меня будет достаточно времени»

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

Answer 4

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

Оказывается, в мире программного обеспечения многие вещи, которые, по вашему мнению, вам не понадобятся, на самом деле вам понадобятся.И еще немного.Кто это думает.

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

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

Answer 5

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

Answer 6

Если вы собираетесь по-настоящему разработать революционное веб-приложение для корпоративного рынка Я не совсем уверен, какая из этих вещей ДаОУ Аинтервал гонна Несть.

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

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

Просто мой 0,2

Answer 7

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

Answer 8

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

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

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

Answer 9

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

Answer 10

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

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

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

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

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

Answer 11

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

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

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

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

Answer 12

Я бы сделал следующее:

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

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

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

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

Answer 13

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

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

Answer 14

Да, НО...

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

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

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

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