YAGNI w tworzeniu aplikacji: co to jest, istota zasady i praktyczne korzyści

Co to jest YAGNI?

YAGNI (You Aren't Gonna Need It) — zasada programowania ekstremalnego (XP), oznaczająca „nie będzie ci to potrzebne“. Reguła głosi: nigdy nie implementuj funkcjonalności, która nie jest wymagana przez bieżące historie użytkownika. Jeśli funkcja nie jest potrzebna dzisiaj — nie rób jej nawet „na wszelki wypadek“.

Termin został wprowadzony przez Rona Jeffriesa, jednego ze współautorów metodologii XP (z Kentem Beckiem). Jeffries twierdził: „Zaimplementuj najprostszą rzecz, która działa, i nie dodawaj niczego, dopóki nie będzie potrzebne“. YAGNI — to nie zakaz planowania, ale zakaz przedwczesnej implementacji.

Według danych Standish Group CHAOS Report (2023), 64% funkcji w przeciętnym produkcie programistycznym jest używanych rzadko lub w ogóle. Jeśli ekstrapolować to na aplikację mobilną — ponad połowa napisanego kodu nie przynosi wartości użytkownikowi. YAGNI zapobiega temu marnowaniu zasobów.

Stosuj YAGNI jako ścisły filtr: każda funkcja musi odpowiedzieć na pytanie „jaki problem konkretnego użytkownika rozwiązuje właśnie teraz?“ Jeśli odpowiedzi brak — funkcja nie jest potrzebna.

Różnica między YAGNI a lenistwem i obcinaniem kantów

YAGNI — to nie rezygnacja z jakościowej architektury. YAGNI zabrania pisania zbędnego kodu, ale nie zabrania pisania poprawnego kodu. Jeśli dla bieżącej funkcji potrzebna jest czysta warstwa abstrakcji — stwórz ją. Jeśli warstwa nie jest potrzebna — nie twórz. Kluczowa różnica: YAGNI dotyczy funkcjonalności, a nie jakości.

Deweloperzy często mylą YAGNI z celowym gromadzeniem długu technicznego (dług techniczny to zawsze kompromis, YAGNI to zasada efektywności). Różnica polega na tym, że dług techniczny jest świadomy i udokumentowany, a naruszenie YAGNI to po prostu zbędna praca.

Zadaj sobie pytanie: „Jeśli nie zrobię tej abstrakcji teraz, ile czasu zajmie refaktoryzacja, gdy będzie potrzebna?“ Jeśli czas refaktoryzacji jest krótszy niż czas pisania teraz — odłóż to.

Dlaczego YAGNI jest krytyczny dla projektów mobilnych?

Tworzenie aplikacji mobilnych jest szczególnie wrażliwe na naruszenie YAGNI z trzech powodów: rozmiar APK/IPA bezpośrednio wpływa na konwersję instalacji, czas kompilacji projektów mobilnych rośnie liniowo z objętością kodu, a każda zbędna funkcja dodaje punkty awarii. YAGNI — nie chodzi o lenistwo, ale o skupienie.

Badanie Google Play Console Data (2023) wykazało: każde 10 MB rozmiaru APK zmniejsza prawdopodobieństwo instalacji o 1,2%. Nieużywany kod to nie tylko śmieci w repozytorium, to bezpośrednie straty finansowe. Zbędne biblioteki (dla funkcjonalności, którą „może dodamy później“) — najczęstsze źródło rozdęcia APK.

Według Gradle Build Performance Report (2024), każdy dodatkowy moduł w projekcie Android zwiększa czas pełnej kompilacji o 3–7 sekund. Jeśli dodasz 5 modułów „na przyszłość“ — wzrost czasu kompilacji wyniesie 15–35 sekund przy każdym buildzie. W ciągu roku zespół 5 deweloperów traci do 200 roboczogodzin na oczekiwanie na kompilację.

Monitoruj rozmiar pliku binarnego w CI: ustaw limit ostrzeżenia (np. +500 KB na commit). Jeśli rozmiar wzrósł bez nowej funkcji — to naruszenie YAGNI, które należy omówić na code review.

YAGNI a gold-plating: praktyczne przykłady

Gold-plating: przedwczesna animacja

Gold-plating — dodawanie funkcjonalności ponad wymagania w próbie „ulepszenia“ produktu. Typowy przykład: deweloper dodaje złożoną animację przejścia między ekranami, choć w projekcie wskazano prosty fade. Animacja zajmuje 2 dni, użytkownik jej nie zauważa, a błędy na różnych urządzeniach prześladują projekt latami.

Według danych UX Collective Annual Report (2023), 78% użytkowników ocenia aplikację po szybkości i stabilności, a nie po animacjach. YAGNI mówi: jeśli animacja nie jest określona w wymaganiach — nie implementuj jej. Projektant doda animację, gdy będzie rzeczywiście potrzebna do rozwiązania problemu UX.

Implementuj tylko to, co jest w makietach. Jeśli projektant nie narysował animacji — oznacza to, że jej nie powinno być. Każde odstępstwo od makiety to naruszenie YAGNI.

Przedwczesna lokalizacja na 20 języków

Częsty błąd startupów: od razu zakładać obsługę 20+ języków „na przyszłe wejście na rynek międzynarodowy“. YAGNI zaleca: lokalizuj tylko na język bieżącego rynku. Dodanie każdego nowego języka wymaga czasu tłumaczy, testowania ciągów pod kątem obcinania i debugowania układu RTL.

Badanie Deloitte Digital Globalization Survey (2022) wykazało: 60% aplikacji mobilnych nigdy nie wychodzi poza pierwszy rynek. Jeśli to twój przypadek — zasoby na wielojęzyczność są zmarnowane. Podejście YAGNI: angielski (podstawowy) + język rynku docelowego. Reszta — w miarę rzeczywistego wejścia na region.

Używaj YAGNI do priorytetyzacji: jeśli funkcja nie znajduje się w roadmapie najbliższych dwóch kwartałów — nie rozpoczynaj jej. Roadmapa musi być dokumentowo zatwierdzona przez product managera.

Jak stosować YAGNI w Android i iOS?

YAGNI w Android: nie dodawaj zbędnych bibliotek

Projekty Android cierpią na inflację biblioteczną. Deweloperzy podłączają Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore — jeszcze zanim napisana zostanie pierwsza linia logiki biznesowej. YAGNI zaleca: podłączaj biblioteki w miarę rzeczywistej potrzeby, a nie prewencyjnie.

// Naruszenie YAGNI: prewencyjne dołączanie bibliotek
// 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")

// A aplikacja na razie pokazuje tylko "Hello World"

Biblioteki to zależności z własną złożonością. Każda wymaga aktualizacji wersji, migracji przy breaking changes i zwiększa rozmiar APK. Podłączaj bibliotekę, gdy pojawi się konkretne zadanie rozwiązywane przez tę bibliotekę. Zacznij od OkHttp (minimalny klient HTTP), dodaj Retrofit, gdy potrzebny będzie klient REST, itd.

YAGNI w iOS: nie forsuj SwiftUI

SwiftUI — potężny framework, ale jego wdrożenie powinno być podyktowane rzeczywistymi potrzebami. Jeśli projekt startuje z iOS 14+ i wymagania dotyczące niestandardowych komponentów UI są minimalne — SwiftUI to dobry wybór. Jeśli projekt musi obsługiwać iOS 13 lub wymaga złożonych niestandardowych gestów — UIKit pozostaje właściwym rozwiązaniem. YAGNI przeciwko migracji na SwiftUI „bo to modne“.

// YAGNI: używaj UIKit, dopóki nie ma realnej korzyści ze SwiftUI
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Profil"
    }
}

// Jeśli potrzebujesz SwiftUI — wdrażaj przez UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Analiza Point-Free: „SwiftUI vs UIKit Decision Guide“ (2024) zaleca: nie migruj istniejących ekranów UIKit na SwiftUI bez wyraźnej biznesowej przyczyny (np. potrzeba Live Preview dla projektanta). Przepisywanie działającego kodu to bezpośrednie naruszenie YAGNI. SwiftUI — dla nowych ekranów, UIKit — dla istniejących.

Typowe błędy przy stosowaniu YAGNI

YAGNI jako usprawiedliwienie złej architektury

Najbardziej niebezpieczny błąd — używać YAGNI jako usprawiedliwienia dla złej architektury. „Nie będziemy wydzielać warstwy repozytorium, bo YAGNI — napiszemy zapytanie prosto w ViewModel“. To nie jest YAGNI, to gromadzenie długu technicznego. YAGNI zabrania zbędnej funkcjonalności, a nie integralności architektonicznej.

Architektura to inwestycja w utrzymywalność. Jeśli piszesz więcej niż 3 ekrany — podstawowa warstwa architektoniczna (MVVM, repozytorium) jest już uzasadniona. Jeśli 1 ekran — możesz pozwolić sobie na proste podejście. Klucz: określaj architektoniczne minimum niezbędne dla bieżących funkcji i nie dodawaj więcej.

Podziel decyzje na „architektoniczne“ i „funkcjonalne“. Decyzje architektoniczne (warstwy, nawigacja, DI) nie podlegają YAGNI — są potrzebne do utrzymywalności. Funkcjonalne (funkcje, zrzuty ekranu, animacje) — podlegają.

Ślepe stosowanie YAGNI przy pracy z API

Inna skrajność — ignorowanie przyszłych kontraktów API. Deweloper otrzymuje z backendu JSON z 5 polami i parsuje tylko 3, bo „pozostałe nie są potrzebne według YAGNI“. Problem: przy dodaniu pola backend może zepsuć parsowanie, jeśli odpowiedź się zmieni. Rozwiązanie — mapowanie wszystkich pól odpowiedzi, nawet jeśli nie wszystkie są teraz używane.

Według Meta API Design Guidelines (2023), klient powinien parsować wszystkie pola, które zwraca serwer, ignorując nieużywane, ale nie odrzucając całej struktury. YAGNI tutaj dotyczy czegoś innego: nie trzeba dodawać obsługi pól, których jeszcze nie ma w specyfikacji, „na wypadek, gdyby backend je zwrócił“.

Parsuj całą strukturę odpowiedzi (wszystkie pola, które serwer zwraca teraz). Nie dodawaj obsługi pól, których nie ma w bieżącej specyfikacji API. To równowaga między YAGNI a odpornością na zmiany.