Как далеко вы идете с YAGNI?
Я занимаюсь разработкой нового революционного веб-приложения для корпоративного рынка. Конечно, многие до меня думали, что их веб-приложение будет революционным, только если узнает, что это не так. (Или это так, но бизнес все равно не хорош).
Поэтому я думаю, чтобы выяснить, имеет ли моя идея какую-то тягу с наименьшими затратами, следовать экстремальному ЯГНИ:
Нет функций безопасности (то есть, нет пользователей и т. Д.). Для любого нового клиента я устанавливаю новый экземпляр базы данных и новый экземпляр веб-приложения. Каждый экземпляр веб-приложения защищен паролем http-сервера (дайджест или базовая авторизация, возможно, через https).
Нет интернационализации. Просто английская строка, встроенная в исходный код.
Нет развязки. Просто веб-страницы, которые общаются с базой данных.
Никаких хитростей в исполнении. Нет очередей, кэшей, таймеров, фоновых заданий, асинхронных вызовов и т. Д.
Нет масштабируемости. Нет разделения на базы данных, нет шардов, нет кластеризации или репликации.
Кроме того, используйте YAGNI на микроуровне, когда это необходимо.
Я просто хочу начать проект и как можно быстрее достичь точки, где я могу продать (или попытаться продать) свои инновационные функции с помощью простого и привлекательного пользовательского интерфейса.
Если план не удастся, я буду знать рано. Если это удастся, я посмотрю, чего хотят клиенты. Они хотят французскую версию? Или они хотят пользователей и роли в организации?
Это то, что люди подразумевают под ЯГНИ, или это патологический и преувеличенный пример ЯГНИ?
14 ответов
Я искренне согласен с принципом ЯГНИ, но вы все еще хотите планировать успех. Если приложение нуждается в полном переписывании, когда у него внезапно появилось более десяти пользователей, тогда это YAGNI зашло слишком далеко.
Некоторые вещи, которые вам понадобятся. С моей точки зрения, два наиболее важных момента:
Не стреляйте себе в ногу, не готовя ваше приложение к интернационализации. Если ваше заявление хорошо, интернационализация будет однажды на столе. Кроме того, способность обрабатывать иностранные символы с помощью UTF-8 является абсолютным требованием при создании приложения с нуля в 2010 году. Интернационализация может показаться не столь важной для носителя английского языка, но, поверьте мне, она необходима и является болью интернационализации. приложение позже ужасно.
Подумайте дважды о том, что не имеет функций безопасности. Как насчет организации или группы, которая хочет работать с вашим приложением с пользователями с разными уровнями безопасности. Вполне возможно, что это функция, без которой вы действительно можете обойтись - у меня есть детальная система безопасности, встроенная во многие мои продукты, которая еще не использовала весь свой потенциал. Но хорошо подумайте, может ли ваше конкретное приложение обойтись, даже если оно будет успешным.
Это то, что они называют "прототипирование". Действуй.
Существует тонкость между YAGNI и прототипированием.
Когда это запрошенный пользователем фурит, и вы говорите "нет", это ЯГНИ.
Когда это реализация (I18N, "развязка"(?), Очереди, кэши, таймеры и т. Д.), И вы говорите "нет" себе. Это не совсем ЯГНИ. Это прототипирование.
Большая часть того, что у вас здесь есть, не кажется ориентированной на пользователя. Я бы не назвал это - точно - ЯГНИ.
YAGNI напоминает вам, чтобы вы увидели разницу между тем, что вы можете сделать, и тем, что вам нужно сделать, чтобы удовлетворить ваши требования.
Например, если ваше требование гласит: "пусть люди создают учетные записи и входят в систему", просто используйте стандартные методы авторизации вашей платформы и переходите к следующему требованию.
Ваше веб-приложение может поддерживать OpenID, Active Directory, локальную базу данных, плоский файл и множество других методов аутентификации, но вы можете удовлетворить требования, реализовав самый простой. (Для меня YAGNI подразумевает DTSTTCPW).
"Я могу сделать что-нибудь, если есть достаточно времени"
- Каждый программист, которого я когда-либо встречал
Я не фанат принципа ЯГНИ; Я вижу, что это используется слишком часто в оправдание плохо разработанного программного обеспечения. Конечно, чрезмерно разработанное программное обеспечение - это тоже проблема, но "ЯГНИ" не оставляет много места для фактического анализа воздействия.
Оказывается, в мире программного обеспечения многие вещи, которые, по вашему мнению, вам не понадобятся, вам действительно понадобятся. А потом некоторые. Who'dathunkit.
Я написал одно или два приложения, которые должны были быть одноразовыми или отложенными, которые все еще находятся в производстве через два года. Они - боль, чтобы поддержать.
Особенно, когда речь идет о чем-то вроде безопасности - вам, вероятно, это понадобится.
Если вы доведите "YAGNI" до такой степени (и я буду обходить дискуссии о том, является ли это хорошей идеей, а также дискуссии о том, действительно ли это "YAGNI"), вы должны быть готовы беспощадно рефакторировать свою кодовую базу, чтобы добавить или нет в последующем то, что вы оставляете сейчас без создания Мяча Грязи.
YAGNI - хороший принцип, но не единственный принцип дизайна. Многие из вышеперечисленных имеют смысл быстро представить продукт пользователям. Но если, например, веб-страницы, которые обращаются непосредственно к базе данных, начинают дублироваться, вы обнаружите, что рабская зависимость от одного принципа (YAGNI), исключая другие (в данном случае DRY), ограничит вашу способность отвечать на ваши, я надеюсь, растущее число пользовательских запросов.
Если вы собираетесь по-настоящему разработать революционное веб-приложение для корпоративного рынка, я не совсем уверен, какие из этих вещей вам нужны.
Также ваши примеры довольно специфичны. Например, когда вы говорите: "нет функций безопасности"... я бы сказал, что пользователи - это одна вещь, без которой вы, возможно, можете обойтись, но очистка ваших входных данных - это то, что вы не можете. Также "масштабируемость" - это не вопрос разделения или репликации базы данных, это решения, которые вы принимаете после того, как понимаете, что ваше приложение плохо масштабируется.
Я бы предпочел быть осторожным при использовании YAGNI в качестве руководства по проектированию на высоком уровне. Это лучше всего подходит, когда вы говорите о нечетных функциях продукта или, может быть, об исключительной гибкости компонентов программного обеспечения.
Только мой 0.2
ЯГНИ хорошо, если есть достойный шанс, что он тебе никогда не понадобится. Если вам это не нужно сейчас, но вы почти уверены, что оно понадобится вам в обозримом будущем, то почти всегда проще установить его заранее, чем позже. Когда вы оправдываете, что не реализуете вещи, которые вам не нужны в эту секунду, но почти наверняка понадобятся YAGNI в ближайшем будущем, вот где начинаются проблемы.
Я бы сказал, что если вы начинаете с того, что отбрасываете весь здравый смысл и делаете весь проект самым быстрым из возможных способов, то в итоге вы получите большую кучу неудач... Что ни в коем случае не является революционным (тм).
Если вы действительно хотите знать, будет ли это полезно, сделайте несколько макетов экрана. Может быть, даже просто обычный старый жесткий кодированный HTML. Отнесите их потенциальным клиентам и посмотрите, сможете ли вы войти в дверь. Если некоторые из них начинают кусаться, то разорвать задницу и построить его.
Потребуется время, чтобы оформить контракт, получить оплату и заставить кого-то из сотрудников ваших клиентов действительно начать его использовать. Пока это происходит, постройте его.
Скорее всего, произойдет то, что потенциальные клиенты увидят ваше приложение и, надеюсь, скажут вам, почему оно не работает для них. Поменяй макеты и возвращайся. Повторяйте по мере необходимости, пока у вас не появится интерфейс для вашего продукта, за который кто-то готов платить.
На мой взгляд, YAGNI чаще всего используется в контексте, когда разработчик думает: "О, было бы разумно, если бы мы также добавили функцию X. Она может понадобиться нам в будущем". Никогда не добавляйте функции, которые не являются обязательными.
При этом ваш код всегда должен быть открыт для изменений, если ваш клиент считает, что функция Y абсолютно необходима. Хорошая архитектура обязательна!
Что касается масштабируемости, очередей, кеширования: это зависит. Каковы требования к заявке? Это интранет-сайт, которым пользуются 10 одновременно работающих пользователей, или это популярный сайт с миллионами пользователей. Это зависит. Найдите требования и сделайте это - больше ничего. YAGNI. Если ваше требование изменится; измените ваше приложение - оно должно быть открыто для изменений.
Тот факт, что YAGNI является лишь одним великим руководителем среди многих, хорошо запомнить; иногда YAGNI предлагает одно решение, но есть одинаково веские (или лучшие) причины для предпочтения другого.
Вот одна область, в которой, как мне кажется, некоторые сторонники YAGNI могут пойти далеко: если вы чувствуете себя комфортно с OOD/ полиморфизмом, вам обычно очень мало стоит "запекать" некоторые отличные точки расширения для будущего использования, даже в прототипе.
Вот пример...
Вы создаете прототип веб-приложения, которое включает в себя возможность отображения печатной версии отчета. Вам нужно работать быстро, но у вас хорошее предчувствие, что стейкхолдеры попросят предоставить вам возможность отправить отчет по электронной почте.
В своем Java-коде на стороне сервера скрывайте информацию о том, что отчет готовится для принтера за интерфейсом. Создайте конкретный класс, который расширяет интерфейс, чтобы нести эту ответственность. На самом деле не уходите и напишите версию интерфейса по электронной почте, потому что YAGNI. Но если вы когда-либо сделаете это, вы можете добавить его без бойни к существующим функциям.
На мой взгляд, по умолчанию следует использовать YAGNI, поскольку это позволяет значительно повысить производительность.
Есть некоторые исключения, подумал. Например, если вы разрабатываете стороннюю библиотеку, вам нужно хотя бы немного подумать заранее и предвидеть потребности некоторых будущих пользователей. Это не значит, что вы должны полностью отказаться от YAGNI, но вы не должны следовать ему так же строго, как в случае собственной разработки.
Что бы я сделал, это:
1) Дизайн это с учетом правильных архитектурных решений. Интернационализация и безопасность, вероятно, должны иметь в этом случае.
2) При разработке создайте хуки для тех принципов, которые будут реализованы позже. Поэтому, когда у вас есть время и бюджет, вы можете реализовать их, не занимаясь серьезной реконструкцией.
3) Затем вы можете сосредоточиться на функциях, которые сделают ваше приложение летающим и более важным для ваших потенциальных клиентов.
Так что я думаю, что в этом случае я бы использовал больше подхода KISS, чем "крайний YAGNI", как вы предложили.
Да, но...
Я склонен согласиться со многими вашими соображениями, за исключением "отсутствия разделения", потому что "оно" в YAGNI означает функциональность, а не мыслительные шаги. Введение нескольких абстракций (только тех, которые необходимы для развязки) немедленно окупится с точки зрения ошибок, которые не были сделаны, или ошибок, которые быстрее обнаруживаются и удаляются.
Хороший (потому что это избавляет вас от размышлений) способ представить эти абстракции - использовать хорошую веб-среду и просто следовать предложенному стилю структурирования приложения.
В качестве дополнительного преимущества стало бы намного проще добавить безопасность, интернационализацию, производительность и масштабируемость позже, и ваше поведение YAGNI-сейчас должно стать достаточно безопасным.
(К сожалению, аргумент применяется только в том случае, если вы уже знакомы с веб-фреймворком. Знание царит в царстве ЯГНИ.)