Τζανκ στην ανάπτυξη — τι είναι, γιατί βλάπτει το junk-code και πώς να το αφαιρέσετε

Τι είναι το τζανκ;

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

Το τζανκ χωρίζεται σε τέσσερις κατηγορίες. Πρώτη — περιττές εξαρτήσεις: βιβλιοθήκες που συνδέονται για μία λειτουργία που μπορεί να υλοποιηθεί με τυπικά μέσα. Δεύτερη — νεκρό βάρος: σχολιασμένα μπλοκ, TODO χωρίς δελτία, κενές μέθοδοι και τάξεις stub. Τρίτη — διπλότυπες λύσεις: δύο βιβλιοθήκες που κάνουν το ίδιο πράγμα (π.χ. Gson και Kotlin Serialization στο ίδιο έργο). Τέταρτη — over-engineering: αρχιτεκτονικά επίπεδα που δεν χρησιμοποιούνται αλλά συντηρούνται για το μέλλον.

Σύμφωνα με την έρευνα Stripe Engineering Productivity (2025), η αφαίρεση 10 τοις εκατό τζανκ από ένα τυπικό έργο μειώνει τον χρόνο πλήρους κατασκευής κατά μέσο όρο 22 τοις εκατό. Αιτία: κάθε επιπλέον εξάρτηση αυξάνει το γράφημα κατασκευής, κάθε κενή αφαίρεση απαιτεί χρόνο για κατανόηση, κάθε σχολιασμένο μπλοκ αποσπά την προσοχή.

Η κύρια δυσκολία στην καταπολέμηση του τζανκ είναι η έλλειψη άμεσων συνεπειών. Το έργο με junk-κώδικα μεταγλωττίζεται και λειτουργεί. Τα προβλήματα συσσωρεύονται σταδιακά: η κατασκευή επιβραδύνεται, ο αριθμός των μεταβατικών εξαρτήσεων αυξάνεται και μετά από ένα χρόνο η προσθήκη μιας νέας λειτουργίας διαρκεί δύο φορές περισσότερο από όσο θα έπρεπε.

Εξαρτήσεις junk και πώς να τις εντοπίσετε

Εξαρτήσεις junk — είναι βιβλιοθήκες και πακέτα που είναι συνδεδεμένα στο έργο αλλά δεν χρησιμοποιούνται άμεσα στον κώδικα, ή χρησιμοποιούνται μόνο σε μία λειτουργία που μπορεί να υλοποιηθεί πιο εύκολα με τυπικά API.

Τυπικά παραδείγματα: βιβλιοθήκη για εργασία με JSON όταν το έργο ήδη χρησιμοποιεί Kotlin Serialization (δύο parsers — αυτό είναι τζανκ); η βιβλιοθήκη Apache Commons Lang για μία μέθοδο StringUtils.isEmpty, η οποία αντικαθίσταται από την επέκταση Kotlin isNullOrBlank; βιβλιοθήκη DI που χρησιμοποιείται σε μία από τις δέκα ενότητες, ενώ οι υπόλοιπες λαμβάνουν εξαρτήσεις χειροκίνητα μέσω κατασκευαστή.

Κάθε επιπλέον εξάρτηση δεν είναι μόνο έξτρα κώδικας στο δυαδικό. Είναι επίσης αύξηση της επιφάνειας επίθεσης για ευπάθειες: σύμφωνα με το GitHub Advisory Database (2025), το 40 τοις εκατό των κρίσιμων CVE σε φορητά έργα προέρχονται από μεταβατικές εξαρτήσεις που οι προγραμματιστές δεν ελέγχουν. Όσο λιγότερες οι εξαρτήσεις — τόσο μικρότερη η επιφάνεια επίθεσης.

Ανάλυση εξαρτήσεων έργου Android

// Προβολή δέντρου εξαρτήσεων Gradle
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Εύρεση αχρησιμοποίητων εξαρτήσεων (πρόσθετο Gradle)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Δημιουργία αναφοράς αχρησιμοποίητων βιβλιοθηκών
./gradlew buildHealth

Για iOS χρησιμοποιήστε την εντολή swift package show-dependencies, η οποία εμφανίζει το πλήρες δέντρο εξαρτήσεων. Το εργαλείο Xcode Build Timeline δείχνει πόσο χρόνο προσθέτει κάθε βιβλιοθήκη στην κατασκευή. Εάν μια βιβλιοθήκη καταλαμβάνει το 30 τοις εκατό του χρόνου μεταγλώττισης αλλά χρησιμοποιείται σε μία οθόνη — είναι υποψήφια για αφαίρεση ή αντικατάσταση.

Για Node.js (React Native) χρησιμοποιήστε το depcheck — ένα βοηθητικό πρόγραμμα που βρίσκει αχρησιμοποίητες εξαρτήσεις στο package.json, και το npm-check, το οποίο εμφανίζει επιπλέον παλιές εκδόσεις. Εφαρμόστε τον κανόνα: κάθε νέα εξάρτηση περνά από code review με αιτιολόγηση του γιατί δεν γίνεται με τυπικά μέσα.

Νεκρά imports και σχολιασμένος κώδικας

Νεκρά imports — ο πιο συνηθισμένος τύπος τζανκ. Δεν επηρεάζουν τον χρόνο εκτέλεσης, αλλά αυξάνουν τον χρόνο μεταγλώττισης: ο μεταγλωττιστής επεξεργάζεται κάθε import, ακόμα κι αν δεν χρησιμοποιείται. Σε μεγάλα έργα, η αφαίρεση αχρησιμοποίητων imports μειώνει τον χρόνο κατασκευής κατά 5–10 τοις εκατό.

Τα σύγχρονα IDE επισημαίνουν αυτόματα τα αχρησιμοποίητα imports με γκρι χρώμα. Διαμορφώστε τον αυτόματο καθαρισμό κατά την αποθήκευση αρχείου: στο IntelliJ IDEA — Optimize Imports on the fly, στο Xcode — Editor > Remove Unused Imports. Στο CI προσθέστε έναν έλεγχο: ο linter πρέπει να μπλοκάρει commits με αχρησιμοποίητα imports.

Σχολιασμένος κώδικας — ένας άλλος τύπος τζανκ. Οι προγραμματιστές σχολιάζουν μπλοκ για να μην χάσουν λειτουργικότητα κατά την αναδόμηση. Ωστόσο, το git αποθηκεύει το πλήρες ιστορικό αλλαγών: κάθε διαγεγραμμένος κώδικας μπορεί να αποκατασταθεί με μία εντολή git revert ή git log -S . Ο σχολιασμένος κώδικας στο master είναι ασέβεια προς την ομάδα: κάθε προγραμματιστής ξοδεύει νοητική ενέργεια στο ερώτημα γιατί είναι σχολιασμένο και πότε πρέπει να αποσχολιαστεί.

Κανόνας: στο αποθετήριο δεν υπάρχει σχολιασμένος κώδικας. Εάν ο κώδικας δεν χρειάζεται — διαγράψτε τον οριστικά. Εάν ο κώδικας χρειάζεται αλλά είναι προσωρινά απενεργοποιημένος — χρησιμοποιήστε feature toggle με δελτίο και προθεσμία. Σχόλια όπως // TODO: remove after migration — μην τα αφήνετε χωρίς προθεσμία. Βάλτε ημερομηνία και ορίστε υπενθύμιση στο ημερολόγιο.

Περιττές αφαιρέσεις και over-engineering

Over-engineering — η δημιουργία αρχιτεκτονικών επιπέδων που δεν λύνουν τρέχοντα προβλήματα αλλά απαιτούν συντήρηση. Αυτός είναι ένας από τους πιο δύσκολους τύπους τζανκ επειδή τυπικά ο κώδικας είναι σωστός: ακολουθεί το SOLID, καλύπτεται από δοκιμές και αντιστοιχεί στην αρχιτεκτονική. Το πρόβλημα είναι ότι δεν χρειάζεται.

Το κλασικό παράδειγμα — μια αφηρημένη κλάση UseCase με μία μέθοδο invoke που απλώς καλεί το αποθετήριο. Εάν το UseCase δεν προσθέτει λογική (caching, retry, μετασχηματισμό), αλλά μόνο προωθεί την κλήση — είναι μια περιττή οντότητα. Αυξάνει την πλοήγηση στο έργο: ο προγραμματιστής ανοίγει το UseCase, βλέπει invoke → repository — και το κλείνει. Χρόνος χαμένος, όφελος μηδέν.

Άλλο παράδειγμα — υπερβολική παραμετροποίηση. Μια γενική διεπαφή με έξι παραμέτρους τύπου, που χρησιμοποιείται σε ένα σημείο. Κάθε παράμετρος τύπου είναι γνωσιακό φορτίο: κατά την ανάγνωση του κώδικα πρέπει να κρατάτε έξι τύπους στο μυαλό, αν και στην πραγματικότητα χρησιμοποιούνται μόνο δύο. Εάν η αφαίρεση δεν επαναχρησιμοποιείται — είναι περιττή.

Το κριτήριο αποκοπής: εάν η αφαίρεση δεν επαναχρησιμοποιείται σε τρία διαφορετικά συμφραζόμενα — αφαιρέστε την. Η αφαίρεση δικαιολογείται όταν λύνει πραγματικά ένα πρόβλημα διπλοτυπίας, όχι όταν προβλέπει υποθετικά μελλοντικά σενάρια. Το YAGNI (You Ain't Gonna Need It) — η καλύτερη αρχή πρόληψης του over-engineering.

Εργαλεία ελέγχου τζανκ

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

Για πλήρη έλεγχο, εκτελέστε το buildHealth (Android) ή το depcheck (Node.js) μία φορά ανά sprint. Δημιουργήστε ένα dashboard στο CI που δείχνει τη δυναμική του αριθμού των εξαρτήσεων ανά sprint. Εάν ο αριθμός αυξάνεται αλλά η λειτουργικότητα δεν αυξάνεται αναλογικά — η ομάδα συσσωρεύει τζανκ.

Δώστε προσοχή στα duplicate classes — ένα σφάλμα όταν δύο βιβλιοθήκες περιέχουν την ίδια κλάση. Αυτό δεν είναι μόνο τζανκ, αλλά και άμεση πηγή συγκρούσεων κατασκευής. Στο Gradle, τέτοιες συγκρούσεις επιλύονται μέσω force ή exclude, αλλά κάθε τέτοια επίλυση είναι σήμα ότι μία από τις βιβλιοθήκες είναι περιττή.

Διαδικασία τακτικού καθαρισμού του έργου

Ο καθαρισμός τζανκ δεν είναι εφάπαξ ενέργεια, αλλά τακτική διαδικασία. Χωρίς κανονισμό, το τζανκ επιστρέφει μέσα σε δύο έως τρία sprint. Η καλύτερη πρακτική — αφιερώστε το 10–15 τοις εκατό της χωρητικότητας κάθε sprint σε τεχνικό καθαρισμό, συμπεριλαμβανομένου του ελέγχου τζανκ.

Η διαδικασία αποτελείται από τέσσερα βήματα. Πρώτο — διάγνωση: εκτέλεση εργαλείων, λήψη αναφοράς, ιεράρχηση. Υψηλή προτεραιότητα — εξαρτήσεις με γνωστά CVE και διπλότυπες βιβλιοθήκες. Μεσαία — νεκρά imports και σχολιασμένος κώδικας. Χαμηλή — περιττές αφαιρέσεις (απαιτούν χειροκίνητη ανάλυση).

Δεύτερο — καθαρισμός: αφαίρεση νεκρών εξαρτήσεων, αντικατάσταση διπλότυπων βιβλιοθηκών με μία, αφαίρεση σχολιασμένου κώδικα. Κάθε αλλαγή γίνεται σε ξεχωριστό commit με κατανοητό μήνυμα: «remove unused dependency: gson (replaced by kotlinx.serialization)», «delete commented code in LoginViewModel».

Τρίτο — επαλήθευση: κατασκευή του έργου, εκτέλεση δοκιμών, έλεγχος UI. Εάν μετά την αφαίρεση της εξάρτησης οι δοκιμές περνούν — η εξάρτηση πραγματικά δεν ήταν απαραίτητη. Εάν οι δοκιμές αποτύχουν — σημαίνει ότι κάπου παρέμεινε μια κρυφή αναφορά που δεν εντόπισε ο στατικός αναλυτής.

Τέταρτο — πρόληψη: ενημέρωση της λίστας ελέγχου code review, προσθήκη του κανόνα «καμία νέα εξάρτηση χωρίς αιτιολόγηση» στο Definition of Done, ρύθμιση αυτόματου ελέγχου στο CI. Η πρόληψη είναι ο μόνος τρόπος να αποτραπεί η εκ νέου συσσώρευση τζανκ.