Как далеко Вы идете с YAGNI? [закрытый]

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

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

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

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

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

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

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

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

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

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

Это то, что называется "прототипированием". Вперед.

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

1. Когда это запрашиваемый пользователем featuritis, и вы говорите нет, это YAGNI.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Только мои 0,2

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

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

Однако, поскольку вы используете PHP, хранение в виде TINYINT имеет гораздо больший смысл. Использование 1/0 значений эквивалентно использованию true и false , даже если они возвращены как последовательности в PHP и могут обрабатываться как таковые. Можно просто выполнить if ($ record ['поле']) с результатами в виде логической проверки, вместо того, чтобы постоянно преобразовывать между 'y' и 'n'.

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

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

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

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