Что верно про YAGNI?
YAGNI — не строить под несуществующие требования. Цена преждевременной фичи: постройка, задержка нужного, сопровождение лишнего кода и исправление, если угадали неверно. На тесты, обработку ошибок и чистоту кода принцип не распространяется.
- Типичное нарушение — интерфейс с единственной реализацией «на случай второй БД»
- Спекулятивные параметры, флаги, точки расширения
- Код, который легко изменить, — лучшая подготовка к будущему
А ещё Исключение: решения, которые потом очень дорого менять (формат данных, публичный API)
Подробно
Фаулер раскладывает цену преждевременной фичи на четыре части: постройка, задержка (пока делали это — не делали нужное), сопровождение (лишний код читают и тестируют всю его жизнь) и исправление, если угадали неверно. Важная граница: YAGNI про функциональность и спекулятивные точки расширения. Тесты, обработка ошибок, идемпотентность и внятные границы модулей — это не будущая фича, а то, что делает изменения дешёвыми.
Что хотят услышать
- Суть и цена преждевременной фичи.
- Границы применения.
Частые ошибки
- Прикрывать YAGNI отказ от качества.
- Считать любую абстракцию преждевременной — ось изменений может быть уже видна.
Проверьте себя
Несколько верных вариантов. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✓Цена преждевременной фичи складывается из постройки, задержки, сопровождения и исправления ошибки выбора
- ✓Интерфейс с единственной реализацией «на случай второй БД» — типичное нарушение
- ✗YAGNI оправдывает отказ от тестов, логирования и обработки ошибок до появления явного требования
- ✓Принцип касается спекулятивной функциональности и точек расширения, а не качества кода
Что спросят дальше
- Как отличить назревшую абстракцию от спекулятивной общности?
- Как это соотносится с OCP?
Разбор темы
- DRY, KISS, YAGNI и качество связей
Дублирование знания против дублирования текста, цена преждевременной абстракции, связность и связанность, закон Деметры, каталог code smells и когда рефакторить.
Связанные вопросы
- Два метода расчёта скидки — для розницы и для опта — сегодня содержат идентичный код, но правила задают разные владельцы и они уже расходились в прошлом. Что правильнее сделать? Middle
- Сервис получает через конструктор зависимость типа PostgresOrderRepository (конкретный класс), которую внедряет Spring. Что здесь верно? Middle
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.