YAGNI в разработке приложений: что это, суть принципа и практическая польза

Что такое YAGNI?

YAGNI (You Aren't Gonna Need It) — принцип экстремального программирования (XP), означающий «вам это не понадобится». Правило гласит: никогда не реализуйте функциональность, которая не требуется текущими пользовательскими историями. Если фича не нужна сегодня — не делайте её даже «на всякий случай».

Термин введён Роном Джеффризом, одним из соавторов методологии XP (с Кентом Беком). Джеффриз утверждал: «Реализуйте самую простую вещь, которая работает, и не добавляйте ничего, пока это не потребуется». YAGNI — это не запрет на планирование, а запрет на преждевременную реализацию.

По данным Standish Group CHAOS Report (2023), 64% функций в среднестатистическом программном продукте используются редко или никогда. Если экстраполировать на мобильное приложение — более половины написанного кода не приносит ценности пользователю. YAGNI предотвращает эту трату ресурсов.

Применяйте YAGNI как строгий фильтр: каждая фича должна отвечать на вопрос «какую проблему конкретного пользователя она решает прямо сейчас?» Если ответа нет — фича не нужна.

Отличие YAGNI от лени и срезания углов

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

Разработчики часто путают YAGNI с намеренным накоплением технического долга (технический долг — это всегда компромисс, YAGNI — принцип эффективности). Разница в том, что технический долг осознаётся и документируется, а нарушение YAGNI — это просто лишняя работа.

Спросите себя: «Если я не сделаю эту абстракцию сейчас, сколько времени займёт рефакторинг, когда она понадобится?» Если время рефакторинга меньше, чем время написания сейчас — отложите.

Почему YAGNI критичен для мобильных проектов?

Мобильная разработка особенно чувствительна к нарушению YAGNI по трём причинам: размер APK/IPA напрямую влияет на конверсию установки, время компиляции мобильных проектов растёт линейно с объёмом кода, и каждая лишняя фича добавляет точки отказа. YAGNI — не про лень, а про фокус.

Исследование Google Play Console Data (2023) показало: каждые 10 МБ размера APK снижают вероятность установки на 1.2%. Неиспользуемый код — это не просто мусор в репозитории, это прямые финансовые потери. Лишние библиотеки (для функциональности, которую «может быть, добавим позже») — самый частый источник раздувания APK.

Согласно Gradle Build Performance Report (2024), каждый дополнительный модуль в Android-проекте увеличивает время полной сборки на 3–7 секунд. Если добавить 5 модулей «на будущее» — прирост времени компиляции составит 15–35 секунд на каждой сборке. За год команда из 5 разработчиков теряет до 200 человеко-часов на ожидание компиляции.

Мониторьте размер бинарника в CI: установите лимит предупреждения (например, +500 КБ за коммит). Если размер вырос без новой фичи — это нарушение YAGNI, которое нужно обсудить на code review.

YAGNI против gold-plating: практические примеры

Gold-plating: преждевременная анимация

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

По данным UX Collective Annual Report (2023), 78% пользователей оценивают приложение по скорости и стабильности, а не по анимациям. YAGNI говорит: если анимация не указана в требованиях — не реализуйте её. Дизайнер добавит анимацию, когда она действительно понадобится для решения UX-проблемы.

Реализуйте только то, что есть в макетах. Если дизайнер не нарисовал анимацию — значит, её не должно быть. Любое отклонение от макета — нарушение YAGNI.

Преждевременная локализация на 20 языков

Частая ошибка стартапов: сразу закладывать поддержку 20+ языков «на будущий выход на международный рынок». YAGNI рекомендует: локализуйте только на язык текущего рынка. Добавление каждого нового языка требует времени переводчиков, тестирования строк на обрезку и отладки RTL-верстки.

Исследование Deloitte Digital Globalization Survey (2022) показало: 60% мобильных приложений никогда не выходят за пределы первого рынка. Если это ваш случай — ресурсы на мультиязычность потрачены впустую. YAGNI-подход: английский (базовый) + язык целевого рынка. Остальные — по мере реального выхода на регион.

Используйте YAGNI для приоритизации: если фича не входит в roadmap ближайших двух кварталов — не начинайте её. Roadmap должен быть документально утверждён продакт-менеджером.

Как применять YAGNI в Android и iOS?

YAGNI в Android: не добавляйте лишние библиотеки

Android-проекты страдают от библиотечной инфляции. Разработчики подключают Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore — ещё до того, как написана первая строчка бизнес-логики. YAGNI рекомендует: подключайте библиотеки по мере реальной необходимости, а не превентивно.

// Нарушение YAGNI: превентивное подключение библиотек
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// А приложение пока просто показывает "Hello World"

Библиотеки — это зависимости с собственной сложностью. Каждая требует обновления версий, миграции при breaking changes и увеличивает размер APK. Подключайте библиотеку, когда появляется конкретная задача, решаемая этой библиотекой. Начните с OkHttp (минимальный HTTP-клиент), добавьте Retrofit, когда понадобится REST-клиент, и т. д.

YAGNI в iOS: не форсируйте SwiftUI

SwiftUI — мощный фреймворк, но его внедрение должно быть продиктовано реальными потребностями. Если проект стартует с iOS 14+ и требования к кастомным UI-компонентам минимальны — SwiftUI хороший выбор. Если проект должен поддерживать iOS 13 или требует сложных кастомных жестов — UIKit остаётся правильным решением. YAGNI против миграции на SwiftUI «потому что модно».

// YAGNI: используйте UIKit, пока нет реальной выгоды от SwiftUI
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Профиль"
    }
}

// Если нужна SwiftUI — внедряйте через UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Анализ Point-Free: «SwiftUI vs UIKit Decision Guide» (2024) рекомендует: не мигрируйте существующие UIKit-экраны на SwiftUI без чёткой бизнес-причины (например, необходимость Live Preview для дизайнера). Переписывание работающего кода — прямое нарушение YAGNI. SwiftUI — для новых экранов, UIKit — для существующих.

Типичные ошибки при следовании YAGNI

YAGNI как оправдание плохой архитектуры

Самая опасная ошибка — использовать YAGNI как оправдание для плохой архитектуры. «Мы не будем выделять слой репозитория, потому что YAGNI — напишем запрос прямо во ViewModel». Это не YAGNI, это накопление технического долга. YAGNI запрещает лишнюю функциональность, а не архитектурную целостность.

Архитектура — это инвестиция в поддерживаемость. Если вы пишете больше 3 экранов — базовый архитектурный слой (MVVM, репозиторий) уже оправдан. Если 1 экран — можете позволить себе простой подход. Ключ: определяйте архитектурный минимум, необходимый для текущих фич, и не добавляйте больше.

Разделите решения на «архитектурные» и «функциональные». Архитектурные решения (слои, навигация, DI) не покрываются YAGNI — они нужны для поддерживаемости. Функциональные (фичи, скриншоты, анимации) — покрываются.

Слепое следование YAGNI при работе с API

Другая крайность — игнорирование будущих контрактов API. Разработчик получает от бэкенда JSON с 5 полями и парсит только 3, потому что «остальные не нужны по YAGNI». Проблема: при добавлении поля бэкенд может сломать парсинг, если ответ изменился. Решение — маппинг всех полей ответа, даже если не все используются сейчас.

Согласно Meta API Design Guidelines (2023), клиент должен парсить все поля, которые возвращает сервер, игнорируя неиспользуемые, но не отбрасывая всю структуру. YAGNI здесь о другом: не нужно добавлять обработку полей, которых ещё нет в спецификации, «на случай, если бэкенд их вернёт».

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