YAGNI στην ανάπτυξη εφαρμογών: Τι είναι, η ουσία της αρχής και η πρακτική χρησιμότητα

Τι είναι το YAGNI;

YAGNI (You Aren't Gonna Need It) — αρχή του extreme programming (XP) που σημαίνει «δεν θα το χρειαστείτε». Ο κανόνας λέει: μην υλοποιείτε ποτέ λειτουργικότητα που δεν απαιτείται από τις τρέχουσες ιστορίες χρηστών. Αν μια λειτουργία δεν χρειάζεται σήμερα — μην την κάνετε, ούτε «για κάθε ενδεχόμενο».

Ο όρος εισήχθη από τον Ron Jeffries, έναν από τους συνδημιουργούς της μεθοδολογίας XP (μαζί με τον Kent Beck). Ο Jeffries δήλωσε: «Υλοποιήστε το πιο απλό πράγμα που λειτουργεί και μην προσθέτετε τίποτα μέχρι να χρειαστεί». YAGNI — δεν είναι απαγόρευση σχεδιασμού, αλλά απαγόρευση πρόωρης υλοποίησης.

Σύμφωνα με το Standish Group CHAOS Report (2023), το 64% των λειτουργιών σε ένα μέσο προϊόν λογισμικού χρησιμοποιούνται σπάνια ή ποτέ. Αν γίνει προέκταση σε εφαρμογή mobile — περισσότερος από τον μισό κώδικα που γράφτηκε δεν προσφέρει αξία στον χρήστη. YAGNI αποτρέπει αυτήν τη σπατάλη πόρων.

Εφαρμόστε το YAGNI ως αυστηρό φίλτρο: κάθε λειτουργία πρέπει να απαντά στην ερώτηση «ποιο συγκεκριμένο πρόβλημα χρήστη λύνει αυτήν τη στιγμή;» Αν δεν υπάρχει απάντηση — η λειτουργία δεν χρειάζεται.

Διαφορά του YAGNI από την τεμπελιά και την κοπή γωνιών

YAGNI — δεν είναι απόρριψη ποιοτικής αρχιτεκτονικής. Το YAGNI απαγορεύει τη γραφή περιττού κώδικα, αλλά δεν απαγορεύει τη γραφή σωστού κώδικα. Αν για την τρέχουσα λειτουργία χρειάζεται ένα καθαρό επίπεδο αφαίρεσης — δημιουργήστε το. Αν το επίπεδο δεν χρειάζεται — μην το δημιουργήσετε. Βασική διαφορά: το YAGNI αφορά τη λειτουργικότητα, όχι την ποιότητα.

Οι προγραμματιστές συχνά συγχέουν το YAGNI με τη σκόπιμη συσσώρευση τεχνικού χρέους (το τεχνικό χρέος είναι πάντα συμβιβασμός, το YAGNI είναι αρχή αποδοτικότητας). Η διαφορά είναι ότι το τεχνικό χρέος αναγνωρίζεται και τεκμηριώνεται, ενώ η παραβίαση του YAGNI είναι απλώς περιττή δουλειά.

Ρωτήστε τον εαυτό σας: «Αν δεν κάνω αυτήν την αφαίρεση τώρα, πόσο χρόνο θα πάρει το refactoring όταν χρειαστεί;» Αν ο χρόνος refactoring είναι μικρότερος από τον χρόνο γραφής τώρα — αναβάλετε.

Γιατί το YAGNI είναι κρίσιμο για έργα mobile;

Η ανάπτυξη mobile είναι ιδιαίτερα ευαίσθητη στην παραβίαση του YAGNI για τρεις λόγους: το μέγεθος APK/IPA επηρεάζει άμεσα τη μετατροπή εγκατάστασης, ο χρόνος μεταγλώττισης των mobile έργων αυξάνεται γραμμικά με τον όγκο κώδικα και κάθε επιπλέον λειτουργία προσθέτει σημεία αποτυχίας. YAGNI — δεν αφορά την τεμπελιά, αλλά την εστίαση.

Έρευνα του Google Play Console Data (2023) έδειξε: κάθε 10 MB μεγέθους APK μειώνει την πιθανότητα εγκατάστασης κατά 1,2%. Ο αχρησιμοποίητος κώδικας δεν είναι απλώς σκουπίδια στο αποθετήριο, είναι άμεση οικονομική ζημιά. Περιττές βιβλιοθήκες (για λειτουργικότητα που «ίσως προστεθεί αργότερα») είναι η συχνότερη πηγή διόγκωσης APK.

Σύμφωνα με το Gradle Build Performance Report (2024), κάθε επιπλέον module σε έργο Android αυξάνει τον χρόνο πλήρους build κατά 3–7 δευτερόλεπτα. Αν προστεθούν 5 modules «για το μέλλον» — η αύξηση χρόνου μεταγλώττισης θα είναι 15–35 δευτερόλεπτα ανά build. Σε έναν χρόνο, μια ομάδα 5 προγραμματιστών χάνει έως 200 ανθρωποώρες περιμένοντας τη μεταγλώττιση.

Παρακολουθείτε το μέγεθος του δυαδικού στο CI: ορίστε ένα όριο προειδοποίησης (π.χ., +500 KB ανά commit). Αν το μέγεθος αυξηθεί χωρίς νέα λειτουργία — αυτό είναι παραβίαση του YAGNI που πρέπει να συζητηθεί στο code review.

YAGNI εναντίον gold-plating: πρακτικά παραδείγματα

Gold-plating: πρόωρη κινούμενη εικόνα

Gold-plating — προσθήκη λειτουργικότητας πέρα από τις απαιτήσεις σε μια προσπάθεια «βελτίωσης» του προϊόντος. Τυπικό παράδειγμα: ο προγραμματιστής προσθέτει σύνθετο κινούμενο animation μετάβασης μεταξύ οθονών, αν και η σχεδίαση ορίζει απλό fade. Το animation παίρνει 2 ημέρες, ο χρήστης δεν το παρατηρεί και τα σφάλματα σε διαφορετικές συσκευές ταλαιπωρούν το έργο για χρόνια.

Σύμφωνα με το UX Collective Annual Report (2023), το 78% των χρηστών αξιολογεί την εφαρμογή με βάση την ταχύτητα και τη σταθερότητα, όχι τα animations. YAGNI λέει: αν το animation δεν αναφέρεται στις απαιτήσεις — μην το υλοποιείτε. Ο σχεδιαστής θα προσθέσει animation όταν πραγματικά χρειαστεί για την επίλυση προβλήματος UX.

Υλοποιείτε μόνο ό,τι υπάρχει στα mockups. Αν ο σχεδιαστής δεν σχεδίασε animation — σημαίνει ότι δεν πρέπει να υπάρχει. Οποιαδήποτε απόκλιση από το mockup είναι παραβίαση του YAGNI.

Πρόωρη τοπικοποίηση σε 20 γλώσσες

Συχνό λάθος startups: να προβλέπουν αμέσως υποστήριξη 20+ γλωσσών «για μελλοντική είσοδο στη διεθνή αγορά». YAGNI συνιστά: τοπικοποιήστε μόνο στη γλώσσα της τρέχουσας αγοράς. Η προσθήκη κάθε νέας γλώσσας απαιτεί χρόνο μεταφραστών, δοκιμές περικοπής συμβολοσειρών και εντοπισμό σφαλμάτων διάταξης RTL.

Η έρευνα Deloitte Digital Globalization Survey (2022) έδειξε: το 60% των εφαρμογών mobile δεν ξεπερνούν ποτέ την πρώτη αγορά. Αν αυτό ισχύει για εσάς — οι πόροι για πολυγλωσσία πήγαν χαμένοι. Προσέγγιση YAGNI: Αγγλικά (βασικά) + γλώσσα αγοράς στόχου. Τα υπόλοιπα — ανάλογα με την πραγματική είσοδο στην περιοχή.

Χρησιμοποιήστε το YAGNI για προτεραιοποίηση: αν μια λειτουργία δεν περιλαμβάνεται στο roadmap των επόμενων δύο τριμήνων — μην την ξεκινάτε. Το roadmap πρέπει να είναι τεκμηριωμένο και εγκεκριμένο από τον product manager.

Πώς να εφαρμόσετε το 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 client), προσθέστε Retrofit όταν χρειαστεί REST client κ.ο.κ.

YAGNI στο iOS: μην εξαναγκάζετε το SwiftUI

SwiftUI — ισχυρό framework, αλλά η εφαρμογή του πρέπει να υπαγορεύεται από πραγματικές ανάγκες. Αν το έργο ξεκινά με iOS 14+ και οι απαιτήσεις για προσαρμοσμένα UI components είναι ελάχιστες — το 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 ως δικαιολογίας για κακή αρχιτεκτονική. «Δεν θα δημιουργήσουμε επίπεδο repository επειδή YAGNI — γράψτε το αίτημα απευθείας στο ViewModel». Αυτό δεν είναι YAGNI, είναι συσσώρευση τεχνικού χρέους. YAGNI απαγορεύει την περιττή λειτουργικότητα, όχι την αρχιτεκτονική ακεραιότητα.

Η αρχιτεκτονική είναι επένδυση στη συντηρησιμότητα. Αν γράφετε περισσότερες από 3 οθόνες — το βασικό αρχιτεκτονικό επίπεδο (MVVM, repository) είναι ήδη δικαιολογημένο. Αν 1 οθόνη — μπορείτε να επιτρέψετε μια απλούστερη προσέγγιση. Κλειδί: καθορίστε το αρχιτεκτονικό ελάχιστο που απαιτείται για τις τρέχουσες λειτουργίες και μην προσθέτετε περισσότερα.

Διαχωρίστε τις αποφάσεις σε «αρχιτεκτονικές» και «λειτουργικές». Οι αρχιτεκτονικές αποφάσεις (επίπεδα, πλοήγηση, DI) δεν καλύπτονται από το YAGNI — χρειάζονται για τη συντηρησιμότητα. Οι λειτουργικές αποφάσεις (λειτουργίες, στιγμιότυπα οθόνης, animations) — καλύπτονται.

Τυφλή τήρηση του YAGNI κατά την εργασία με API

Ένα άλλο άκρο — η αγνόηση μελλοντικών συμβολαίων API. Ο προγραμματιστής λαμβάνει JSON από το backend με 5 πεδία και αναλύει μόνο 3 επειδή «τα υπόλοιπα δεν χρειάζονται σύμφωνα με το YAGNI». Πρόβλημα: όταν το backend προσθέσει ένα πεδίο, μπορεί να σπάσει η ανάλυση αν η απάντηση άλλαξε. Λύση — χαρτογράφηση όλων των πεδίων απάντησης, ακόμα και αν δεν χρησιμοποιούνται όλα τώρα.

Σύμφωνα με το Meta API Design Guidelines (2023), ο πελάτης πρέπει να αναλύει όλα τα πεδία που επιστρέφει ο διακομιστής, αγνοώντας τα αχρησιμοποίητα, αλλά όχι απορρίπτοντας ολόκληρη τη δομή. YAGNI εδώ αφορά κάτι άλλο: μην προσθέτετε χειρισμό πεδίων που δεν υπάρχουν ακόμα στην προδιαγραφή, «για την περίπτωση που τα επιστρέψει το backend».

Αναλύστε ολόκληρη τη δομή απάντησης (όλα τα πεδία που επιστρέφει ο διακομιστής τώρα). Μην προσθέτετε χειρισμό πεδίων που δεν υπάρχουν στην τρέχουσα προδιαγραφή API. Αυτή είναι η ισορροπία μεταξύ YAGNI και ανθεκτικότητας στις αλλαγές.