Αντιγραφή-επικόλληση στην ανάπτυξη εφαρμογών — τι είναι, γιατί είναι επικίνδυνο και πώς να το αποφύγετε

Τι είναι η αντιγραφή-επικόλληση;

Αντιγραφή-επικόλληση (copy-paste programming) — είναι η μεταφορά υπάρχοντος κώδικα σε μια νέα θέση με μικρές αλλαγές ή χωρίς αλλαγές. Ο όρος χρησιμοποιείται με υποτιμητική έννοια: υποδηλώνει ότι ο προγραμματιστής δεν σχεδιάζει τη λύση, αλλά αντιγράφει μηχανικά ένα έτοιμο μπλοκ, συχνά χωρίς να κατανοεί πλήρως πώς λειτουργεί.

Η αντιγραφή-επικόλληση είναι δύο τύπων: δικαιολογημένη (intentional) και τυχαία (accidental). Δικαιολογημένη — όταν ο προγραμματιστής αντιγράφει σκόπιμα κώδικα με σχέδιο μεταγενέστερης αναδόμησης (αλλά το σχέδιο συχνά δεν εκτελείται). Τυχαία — όταν η διπλοτυπία προκύπτει απαρατήρητα, για παράδειγμα, δύο προγραμματιστές γράφουν ανεξάρτητα την ίδια λογική για διαφορετικές οθόνες.

Σύμφωνα με την αναφορά SonarQube State of Clean Code (2025), ο διπλοτυπημένος κώδικας αποτελεί κατά μέσο όρο 12–18 τοις εκατό του συνολικού όγκου κώδικα σε εμπορικά έργα. Ταυτόχρονα, το κόστος διόρθωσης ενός σφάλματος σε διπλοτυπημένο κώδικα είναι 2,5 φορές υψηλότερο από ό,τι σε κώδικα με ενιαία υλοποίηση, επειδή ο προγραμματιστής πρέπει να βρει και να διορθώσει όλα τα αντίγραφα.

Το κύριο εργαλείο καταπολέμησης της αντιγραφής-επικόλλησης είναι η αρχή DRY (Don't Repeat Yourself). Ωστόσο, η απολυτοποίηση του DRY είναι επίσης επικίνδυνη: μερικές φορές η αντιγραφή δικαιολογείται όταν δύο αντίγραφα πρέπει να εξελιχθούν ανεξάρτητα το ένα από το άλλο. Είναι σημαντικό να γίνει διάκριση μεταξύ “τυχαίας διπλοτυπίας” (που πρέπει να εξαλειφθεί) και “απαραίτητης διπλοτυπίας” (που πρέπει να τεκμηριωθεί).

Γιατί είναι επικίνδυνη η αντιγραφή-επικόλληση

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

Ο δεύτερος κίνδυνος — άνιση εξέλιξη. Δύο αντίγραφα του ίδιου αλγορίθμου με την πάροδο του χρόνου αποκτούν διαφορετικές τροποποιήσεις. Στο ένα αντίγραφο προστέθηκε επικύρωση οριακών τιμών, στο άλλο — άλλαξε η μορφή εξόδου. Μετά από μερικούς μήνες, καθίσταται αδύνατο να προσδιοριστεί ποια έκδοση είναι “σωστή” και το έργο χάνει τη συνέπεια συμπεριφοράς.

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

Ο τέταρτος κίνδυνος — ψευδαίσθηση παραγωγικότητας. Η αντιγραφή-επικόλληση δημιουργεί μια ψεύτικη αίσθηση ταχύτητας: ο προγραμματιστής εισάγει γρήγορα κώδικα και βλέπει ότι η οθόνη λειτουργεί. Αλλά αυτή η “ταχύτητα” μετατρέπεται σε τεχνική οφειλή που θα πρέπει να αποπληρωθεί με τόκο όταν βρεθεί σφάλμα στο διπλοτυπημένο μπλοκ ή απαιτηθεί αλλαγή της επιχειρηματικής λογικής.

Γιατί οι προγραμματιστές αντιγράφουν κώδικα

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

Η πρώτη αιτία — προθεσμίες. Όταν πρέπει να φτιαχτεί μια οθόνη σε δύο ημέρες και μια παρόμοια οθόνη υπάρχει ήδη, ο προγραμματιστής την αντιγράφει εξ ολοκλήρου και αλλάζει μόνο ό,τι βλέπει ο χρήστης. Για αναδόμηση με εξαγωγή κοινού στοιχείου δεν υπάρχει χρόνος — ο πελάτης περιμένει αποτέλεσμα. Ως αποτέλεσμα, εμφανίζεται μια δεύτερη οθόνη με 80 τοις εκατό κοινό κώδικα, αλλά με ανεξάρτητο ιστορικό αλλαγών.

Η δεύτερη αιτία — έλλειψη ενιαίας αφαίρεσης. Εάν στο έργο δεν υπάρχει κοινό στοιχείο για μια τυπική εργασία (για παράδειγμα, οθόνη λίστας με pull-to-refresh), κάθε προγραμματιστής θα γράψει τη δική του υλοποίηση ή θα αντιγράψει τη γειτονική. Οι αρχιτεκτονικές αποφάσεις που λαμβάνονται στην αρχή του έργου επηρεάζουν άμεσα την ποσότητα της μελλοντικής αντιγραφής-επικόλλησης.

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

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

Εργαλεία ανίχνευσης διπλοτύπων

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

PMD CPD (Copy-Paste Detector) — το πιο διαδεδομένο εργαλείο για Java, Kotlin, Swift, JavaScript, Python και C++. Το CPD αναλύει τα διακριτικά (tokens) του πηγαίου κώδικα και βρίσκει διπλότυπα μεγαλύτερα από ένα καθορισμένο ελάχιστο αριθμό διακριτικών (προεπιλογή 100). Η ρύθμιση του ορίου είναι το κλειδί για ένα ποιοτικό αποτέλεσμα: πολύ χαμηλό όριο δίνει πολλά ψευδώς θετικά (κοινά μοτίβα όπως import), πολύ υψηλό — χάνει πραγματικά διπλότυπα.

Εκτέλεση PMD CPD μέσω Gradle

plugins {
    id 'pmd'
}

pmd {
    toolVersion = '7.0.0'
    ruleSetFiles = files("pmd-rules.xml")
}

tasks.register('cpd') {
    doLast {
        exec {
            workingDir = projectDir
            commandLine 'cpd',
                '--minimum-tokens', '75',
                '--language', 'kotlin',
                '--files', 'src/main/kotlin',
                '--format', 'xml',
                '--failOnViolation', 'true'
        }
    }
}

SonarQube ενσωματώνει τον ανιχνευτή διπλοτύπων απευθείας στο Quality Gate. Ο κανόνας Duplicated Blocks (%) δείχνει το ποσοστό διπλοτυπημένου κώδικα. Το όριο του 5 τοις εκατό θεωρείται υγιές για εμπορικά έργα. Η υπέρβαση αποκλείει την προώθηση στο branch έκδοσης. Το SonarQube επιπλέον ομαδοποιεί τα διπλότυπα ανά τύπο: ακριβή αντίγραφα (exact match) και δομικά αντίγραφα (με τροποποιημένα ονόματα).

Για JavaScript και TypeScript, τα διπλότυπα αναζητούνται με το ESLint και το πρόσθετο eslint-plugin-sonarjs (κανόνας no-duplicate-string) και το βοηθητικό πρόγραμμα jscpd, το οποίο υποστηρίζει 150+ γλώσσες. Το jscpd είναι ιδιαίτερα βολικό για monorepo: βρίσκει διπλότυπα μεταξύ πακέτων, όχι μόνο εντός μιας ενότητας.

Στρατηγικές αναδόμησης διπλοτυπημένου κώδικα

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

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

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

// πριν - δύο αντίγραφα του ίδιου UITableViewController
class UserListController: UITableViewController {
    private let viewModel = UserListViewModel()
    // 40 γραμμές κώδικα
}

class ProductListController: UITableViewController {
    private let viewModel = ProductListViewModel()
    // οι ίδιες 40 γραμμές αλλά με Product αντί για User
}

// μετά - κοινή γενική βασική κλάση
class ListViewController<T: ListViewModel>: UITableViewController {
    let viewModel: T
    // 40 γραμμές κώδικα - μόνο μία φορά

    init(viewModel: T) {
        self.viewModel = viewModel
        super.init(style: .plain)
    }
}

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

Πρόληψη αντιγραφής-επικόλλησης σε επίπεδο ομάδας

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

Το πρώτο μέτρο — code review με έμφαση στη διπλοτυπία. Η λίστα ελέγχου της αναθεώρησης πρέπει να περιλαμβάνει το σημείο: “Υπάρχει σε αυτό το PR κώδικας που ήδη υπάρχει στο έργο;”. Εάν ο αναθεωρητής δει αντιγραφή-επικόλληση — μπλοκάρει τη συγχώνευση μέχρι την εξαγωγή του κοινού στοιχείου. Αυτή η απαίτηση πρέπει να καταγραφεί στο Definition of Done της ομάδας.

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

Το τρίτο μέτρο — αυτοματοποίηση στο CI/CD. Προσθέστε ένα βήμα στη γραμμή παραγωγής με έλεγχο διπλοτυπημένου κώδικα (PMD CPD, jscpd, SonarQube). Η υπέρβαση ορίου — σφάλμα δόμησης. Ο προγραμματιστής δεν μπορεί να συγχωνεύσει ένα PR που αυξάνει το ποσοστό αντιγραφής-επικόλλησης πάνω από το επιτρεπόμενο επίπεδο. Αυτό μεταφέρει την ευθύνη από το code review στην αυτοματοποίηση και εγγυάται ότι κανένα διπλότυπο δεν θα παραλειφθεί.

Εισαγάγετε την κουλτούρα “μία υλοποίηση — ένα μέρος”. Αν βλέπετε δυνατότητα επαναχρησιμοποίησης — μην αναβάλλετε την αναδόμηση για αργότερα. Κάθε αντιγραφή-επικόλληση που αφήνεται “για αργότερα” πολλαπλασιάζεται και μετατρέπεται σε ανεξέλεγκτη τεχνική οφειλή.