YAGNI i apputveckling: vad det är, principens kärna och praktisk nytta

Vad är YAGNI?

YAGNI (You Aren't Gonna Need It) — princip inom extrem programmering (XP) som betyder "du kommer inte att behöva det". Regeln säger: implementera aldrig funktionalitet som inte krävs av aktuella användarberättelser. Om en funktion inte behövs idag — gör den inte, inte ens "för säkerhets skull".

Termen introducerades av Ron Jeffries, en av medförfattarna till XP-metodologin (tillsammans med Kent Beck). Jeffries sade: "Implementera det enklaste som fungerar och lägg inte till något förrän det behövs." YAGNI — inte ett förbud mot planering, utan ett förbud mot förtida implementering.

Enligt Standish Group CHAOS Report (2023) används 64% av funktionerna i en genomsnittlig mjukvaruprodukt sällan eller aldrig. Om man extrapolerar till en mobilapplikation — mer än hälften av den skrivna koden ger inget värde för användaren. YAGNI förhindrar detta resursslöseri.

Tillämpa YAGNI som ett strikt filter: varje funktion måste svara på frågan "vilket specifikt användarproblem löser den just nu?" Om det inte finns något svar — behövs inte funktionen.

Skillnaden mellan YAGNI och lathet samt genvägar

YAGNI — inte ett avvisande av kvalitativ arkitektur. YAGNI förbjuder att skriva överflödig kod, men förbjuder inte att skriva korrekt kod. Om den aktuella funktionen behöver ett rent abstraktionslager — skapa det. Om lagret inte behövs — skapa det inte. Huvudskillnad: YAGNI handlar om funktionalitet, inte om kvalitet.

Utvecklare blandar ofta ihop YAGNI med avsiktlig ackumulering av teknisk skuld (teknisk skuld är alltid en kompromiss, YAGNI är en effektivitetsprincip). Skillnaden är att teknisk skuld är medveten och dokumenterad, medan brott mot YAGNI bara är extra arbete.

Fråga dig själv: "Om jag inte gör denna abstraktion nu, hur lång tid tar refaktoriseringen när den behövs?" Om refaktoriseringstiden är kortare än skrivtiden nu — skjut upp.

Varför är YAGNI kritiskt för mobilprojekt?

Mobilutveckling är särskilt känslig för brott mot YAGNI av tre skäl: APK/IPA-storlek påverkar direkt installationskonverteringen, kompileringstiden för mobilprojekt ökar linjärt med kodmängden och varje extra funktion lägger till felpunkter. YAGNI — handlar inte om lathet, utan om fokus.

Forskning från Google Play Console Data (2023) visade: varje 10 MB APK-storlek minskar sannolikheten för installation med 1,2%. Oanvänd kod är inte bara skräp i arkivet, det är en direkt ekonomisk förlust. Överflödiga bibliotek (för funktionalitet som "kanske läggs till senare") är den vanligaste källan till APK-svullnad.

Enligt Gradle Build Performance Report (2024) ökar varje extra modul i ett Android-projekt tiden för fullständig byggnad med 3–7 sekunder. Om man lägger till 5 moduler "för framtiden" — blir ökningen av kompileringstiden 15–35 sekunder per byggnad. På ett år förlorar ett team på 5 utvecklare upp till 200 arbetstimmar på att vänta på kompilering.

Övervaka binärstorleken i CI: sätt en varningsgräns (t.ex. +500 KB per commit). Om storleken ökar utan ny funktion — är det ett brott mot YAGNI som måste diskuteras i code review.

YAGNI mot gold-plating: praktiska exempel

Gold-plating: förtida animation

Gold-plating — att lägga till funktionalitet utöver kraven i ett försök att "förbättra" produkten. Typiskt exempel: utvecklaren lägger till komplex övergångsanimation mellan skärmar, trots att designen anger enkel fade. Animationen tar 2 dagar, användaren märker den inte och buggar på olika enheter hemsöker projektet i åratal.

Enligt UX Collective Annual Report (2023) bedömer 78% av användarna applikationen baserat på hastighet och stabilitet, inte animationer. YAGNI säger: om animationen inte anges i kraven — implementera den inte. Designern lägger till animation när den verkligen behövs för att lösa ett UX-problem.

Implementera bara det som finns i mockuperna. Om designern inte ritade en animation — betyder det att den inte ska finnas. Varje avvikelse från mockupen är ett brott mot YAGNI.

Förtida lokalisering till 20 språk

Vanligt misstag hos startups: att omedelbart planera stöd för 20+ språk "för framtida inträde på den internationella marknaden". YAGNI rekommenderar: lokalisera endast till språket på den aktuella marknaden. Att lägga till varje nytt språk kräver översättares tid, testning av strängbeskärning och felsökning av RTL-layout.

Undersökningen Deloitte Digital Globalization Survey (2022) visade: 60% av mobilapplikationerna når aldrig längre än den första marknaden. Om detta är ditt fall — har resurserna för flerspråkighet gått till spillo. YAGNI-metod: engelska (grundläggande) + målgruppens språk. Övriga — efter faktisk marknadsinträde.

Använd YAGNI för prioritering: om en funktion inte ingår i färdplanen för de närmaste två kvartalen — börja inte med den. Färdplanen måste vara dokumenterad och godkänd av produktchefen.

Hur tillämpar man YAGNI i Android och iOS?

YAGNI i Android: lägg inte till onödiga bibliotek

Android-projekt lider av biblioteksinflation. Utvecklare lägger till Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore — redan innan den första raden affärslogik har skrivits. YAGNI rekommenderar: lägg till bibliotek enligt faktiskt behov, inte förebyggande.

// Brott mot YAGNI: preventivt tillägg av 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")

// Applikationen visar för närvarande bara “Hello World”

Bibliotek är beroenden med egen komplexitet. Varje kräver versionsuppdateringar, migrering vid brytande förändringar och ökar APK-storleken. Lägg till ett bibliotek när det finns en specifik uppgift som biblioteket löser. Börja med OkHttp (minimal HTTP-klient), lägg till Retrofit när REST-klient behövs, och så vidare.

YAGNI i iOS: tvinga inte SwiftUI

SwiftUI — ett kraftfullt ramverk, men dess införande bör styras av verkliga behov. Om projektet startar med iOS 14+ och kraven på anpassade UI-komponenter är minimala — är SwiftUI ett bra val. Om projektet måste stödja iOS 13 eller kräver komplexa anpassade gester — förblir UIKit rätt lösning. YAGNI är emot migrering till SwiftUI "för att det är modernt".

// YAGNI: använd UIKit tills det finns verklig fördel med SwiftUI
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Profil"
    }
}

// Om SwiftUI behövs — implementera via UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Analysen från Point-Free: "SwiftUI vs UIKit Decision Guide" (2024) rekommenderar: migrera inte befintliga UIKit-skärmar till SwiftUI utan tydlig affärsanledning (t.ex. behov av Live Preview för designern). Att skriva om fungerande kod är direkt brott mot YAGNI. SwiftUI — för nya skärmar, UIKit — för befintliga.

Typiska misstag vid följande av YAGNI

YAGNI som ursäkt för dålig arkitektur

Det farligaste misstaget är att använda YAGNI som ursäkt för dålig arkitektur. "Vi skapar inte ett repository-lager eftersom YAGNI — skriv förfrågan direkt i ViewModel." Detta är inte YAGNI, det är ackumulering av teknisk skuld. YAGNI förbjuder överflödig funktionalitet, inte arkitektonisk integritet.

Arkitektur är en investering i underhållbarhet. Om du skriver mer än 3 skärmar — är det grundläggande arkitektoniska lagret (MVVM, repository) redan motiverat. Om 1 skärm — kan du tillåta dig en enklare metod. Nyckel: bestäm det arkitektoniska minimum som krävs för aktuella funktioner och lägg inte till mer.

Dela upp beslut i "arkitektoniska" och "funktionella". Arkitektoniska beslut (lager, navigering, DI) täcks inte av YAGNI — de behövs för underhållbarhet. Funktionella beslut (funktioner, skärmbilder, animationer) — täcks.

Blind följning av YAGNI vid arbete med API

En annan extrem — ignorering av framtida API-kontrakt. Utvecklaren tar emot JSON från backend med 5 fält och parsar bara 3 eftersom "övriga behövs inte enligt YAGNI". Problem: när backend lägger till ett fält kan parsningen gå sönder om svaret ändrades. Lösning — kartläggning av alla svarsfält, även om inte alla används nu.

Enligt Meta API Design Guidelines (2023) bör klienten parsa alla fält som servern returnerar, ignorera oanvända men inte kasta bort hela strukturen. YAGNI här handlar om något annat: lägg inte till hantering av fält som ännu inte finns i specifikationen, "ifall backend returnerar dem".

Parsa hela svarsstrukturen (alla fält som servern för närvarande returnerar). Lägg inte till hantering av fält som inte finns i den aktuella API-specifikationen. Detta är balansen mellan YAGNI och motståndskraft mot förändringar.