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 MB величине APK-а смањују вероватноћу инсталације за 1,2%. Некоришћени код није само ђубре у репозиторијуму, већ директни финансијски губици. Сувишне библиотеке (за функционалност коју „можда ћемо касније додати“) — најчешћи извор надувања APK-а.

Gradle Build Performance Report (2024), сваки додатни модул у Android пројекту повећава време пуне компилације за 3–7 секунди. Ако додате 5 модула „за будућност“ — пораст времена компилације ће бити 15–35 секунди при сваком билду. Током године, тим од 5 програмера губи до 200 радних сати чекајући компилацију.

Пратите величину бинарног фајла у CI-ју: поставите границу упозорења (нпр. +500 KB по комиту). Ако је величина порасла без нове функције — то је кршење 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 за приоритизацију: ако функција није у роадмапу за следећа два квартала — не започињујте је. Роадмап мора бити документовано одобрен од стране продакт менаџера.

Како примењивати 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 поља са backend-а и парсира само 3, јер „остали нису потребни према YAGNI“. Проблем: при додавању поља, backend може да поквари парсирање ако се одговор променио. Решење — мапирање свих поља одговора, чак и ако се не користе сада.

Према Meta API Design Guidelines (2023), клијент треба да парсира сва поља која сервер враћа, игноришући некоришћена, али не одбацујући целу структуру. YAGNI овде је о нечем другом: не треба додавати обраду поља која још нису у спецификацији, „у случају да их backend врати“.

Парсирајте целу структуру одговора (сва поља која сервер враћа сада). Не додајте обраду поља која нису у текућој API спецификацији. То је равнотежа између YAGNI и отпорности на промене.