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 та стійкістю до змін.