Copypaste nello sviluppo di applicazioni — cosa è, perché è pericoloso e come evitarlo

Cos'è il copypaste?

Copypaste (programmazione copia e incolla) è lo spostamento di codice esistente in un nuovo posto con pochi o nessun cambiamento. Il termine è usato in senso peggiorativo: implica che lo sviluppatore non sta progettando una soluzione, ma sta copiando meccanicamente un blocco già pronto, spesso senza comprendere appieno come funziona.

Il copypaste si presenta in due forme: intenzionale e accidentale. Intenzionale — quando uno sviluppatore copia deliberatamente codice con l'intenzione di rifattorizzarlo in seguito (ma il piano viene spesso abbandonato). Accidentale — quando la duplicazione sorge inosservata, per esempio, due sviluppatori scrivono indipendentemente la stessa logica per schermate diverse.

Secondo il rapporto SonarQube State of Clean Code (2025), il codice duplicato rappresenta in media il 12–18 per cento del volume totale di codice nei progetti commerciali. Allo stesso tempo, il costo della correzione di un bug nel codice duplicato è 2.5 volte superiore rispetto al codice con implementazione singola, perché lo sviluppatore deve trovare e correggere tutte le copie.

Lo strumento principale contro il copypaste è il principio DRY (Don't Repeat Yourself). Tuttavia, assolutizzare il DRY è anche pericoloso: a volte copiare è giustificato quando due copie devono evolvere indipendentemente l'una dall'altra. È importante distinguere tra “duplicazione accidentale” (che va eliminata) e “duplicazione necessaria” (che va documentata).

Perché il copypaste è pericoloso

Il primo e più critico pericolo è la propagazione dei bug. Se il codice originale ha un difetto, viene copiato in tutte le nuove posizioni insieme al codice. Quando il difetto viene scoperto e corretto nel modulo originale, le copie rimangono non corrette. Lo sviluppatore potrebbe nemmeno sapere che il bug esiste in cinque file diversi.

Il secondo pericolo è l'evoluzione disuguale. Due copie dello stesso algoritmo accumulano modifiche diverse nel tempo. Una copia aggiunge la validazione dei valori limite, un'altra cambia il formato di output. Dopo alcuni mesi, diventa impossibile sapere quale versione sia “corretta” e il progetto perde coerenza comportamentale.

Il terzo pericolo è l'aumento del volume dei test. Ogni istanza di copypaste richiede i propri test. Se la logica comune viene estratta in un'unica funzione, può essere coperta con un set di test e riutilizzata. Con la duplicazione, ogni copia deve essere testata separatamente — questo moltiplica il tempo di esecuzione della CI e la dimensione della base di test da mantenere.

Il quarto pericolo è l'illusione di produttività. Il copypaste crea una falsa sensazione di velocità: lo sviluppatore incolla rapidamente il codice e vede che la schermata funziona. Ma questa “velocità” si trasforma in debito tecnico che dovrà essere ripagato con gli interessi quando verrà trovato un bug nel blocco duplicato o sarà necessario un cambiamento nella logica di business.

Perché gli sviluppatori copiano il codice

Comprendere le ragioni del copypaste aiuta a stabilire una prevenzione adeguata. Molto spesso, gli sviluppatori copiano codice non per pigrizia, ma a causa della pressione delle scadenze, della mancanza di conoscenza o di un'architettura scomoda.

La prima ragione sono le scadenze. Quando una schermata deve essere realizzata in due giorni e una schermata simile esiste già, lo sviluppatore la copia interamente e modifica solo ciò che l'utente vede. Non c'è tempo per rifattorizzare ed estrarre un componente condiviso — il cliente esige risultati. Di conseguenza, appare una seconda schermata con l'80 per cento di codice condiviso ma una cronologia di modifiche indipendente.

La seconda ragione è la mancanza di un'astrazione unificata. Se il progetto non ha un componente condiviso per un compito tipico (ad esempio, una schermata di elenco con pull-to-refresh), ogni sviluppatore scriverà la propria implementazione o copierà quella del vicino. Le decisioni architetturali prese all'inizio del progetto influenzano direttamente la quantità di copypaste futuro.

La terza ragione è la paura di rompere codice funzionante. Lo sviluppatore sa che il modulo esistente funziona. Rifattorizzare per estrarre codice condiviso potrebbe influenzare la funzionalità esistente. Se la copertura dei test è bassa, il rischio di rottura supera il beneficio percepito del refactoring, e lo sviluppatore sceglie la via sicura — copiare.

Affrontate le cause, non i sintomi. Ridurre le scadenze e introdurre la revisione del codice non risolverà il problema se al progetto manca una solida base architetturale. Investite tempo nella creazione di componenti riutilizzabili nelle fasi iniziali — è l'unico modo per ridurre la tentazione del copypaste in futuro.

Strumenti di rilevamento dei duplicati

Il rilevamento del copypaste viene eseguito da analizzatori automatici che confrontano frammenti di codice e identificano corrispondenze al di sopra di una determinata soglia. I migliori strumenti operano a livello di AST (Albero Sintattico Astratto) e ignorano formattazione, nomi di variabili e commenti.

PMD CPD (Copy-Paste Detector) è lo strumento più comune per Java, Kotlin, Swift, JavaScript, Python e C++. CPD analizza i token del codice sorgente e trova duplicati più lunghi di un numero minimo specificato di token (default 100). Configurare la soglia è fondamentale per ottenere risultati di qualità: una soglia troppo bassa genera molti falsi positivi (pattern comuni come gli import), una soglia troppo alta perde duplicati reali.

Eseguire PMD CPD tramite 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 incorpora un rilevatore di duplicati direttamente nel Quality Gate. La regola Duplicated Blocks (%) mostra la percentuale di codice duplicato. Una soglia del 5 per cento è considerata sana per i progetti commerciali. Il superamento blocca la promozione al ramo di rilascio. SonarQube raggruppa inoltre i duplicati per tipo: corrispondenze esatte e copie strutturali (con identificatori rinominati).

Per JavaScript e TypeScript, i duplicati vengono rilevati utilizzando ESLint con il plugin eslint-plugin-sonarjs (regola no-duplicate-string) e l'utility jscpd, che supporta oltre 150 linguaggi. jscpd è particolarmente utile per i monorepo: trova duplicati tra i pacchetti, non solo all'interno di un singolo modulo.

Strategie per il refactoring del codice duplicato

Il refactoring del copypaste si riduce a un principio: estrarre la parte comune e parametrizzare le differenze. La tecnica specifica dipende dall'estensione della duplicazione e dal contesto.

Il caso più semplice è la duplicazione all'interno di una stessa classe (ad esempio, due metodi con la stessa logica ma tipi diversi). La soluzione è generalizzare con i generics o riutilizzare un metodo con un parametro di tipo. Se la duplicazione si estende su più classi — estraete il codice comune in una classe di utilità o funzione di estensione.

Un caso più complesso è la duplicazione a livello di schermata o modulo. Qui, la semplice estrazione di una funzione non aiuta, perché la struttura dell'interfaccia utente, la logica del ciclo di vita e il data binding sono tutti duplicati. La soluzione è creare una classe base di schermata comune o un componente di vista composito, e passare le differenze tramite parametri o un protocollo.

// before - two copies of the same UITableViewController
class UserListController: UITableViewController {
    private let viewModel = UserListViewModel()
    // 40 lines of code
}

class ProductListController: UITableViewController {
    private let viewModel = ProductListViewModel()
    // same 40 lines but with Product instead of User
}

// after - generic base class shared
class ListViewController<T: ListViewModel>: UITableViewController {
    let viewModel: T
    // 40 lines of code - once only

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

Il caso più complesso è la duplicazione tra microservizi o librerie. Estrarre codice condiviso può portare a dipendenze circolari o accoppiamento ingiustificato. In tali casi, il copypaste può essere una decisione consapevole: due team mantengono servizi indipendenti e una libreria condivisa crea più problemi di quanti ne risolva. La chiave è documentare tale decisione e verificare regolarmente se le copie sono divergenti abbastanza da giustificare l'unificazione.

Prevenzione del copypaste a livello di team

Prevenire il copypaste è più efficace che rifattorizzare codice già duplicato. Le principali misure preventive risiedono nell'organizzazione del processo di sviluppo, non nella tecnologia.

La prima misura è la revisione del codice con attenzione alla duplicazione. La checklist di revisione dovrebbe includere la voce: “Questo PR contiene codice che esiste già nel progetto?” Se il revisore vede copypaste — blocca il merge fino a quando il componente condiviso non viene estratto. Questo requisito dovrebbe far parte della Definition of Done del team.

La seconda misura è una libreria di componenti condivisa. Ogni pattern dell'interfaccia utente che appare su due o più schermate dovrebbe essere estratto in un modulo comune. Create un modulo condiviso nel progetto e rendetelo il punto di ingresso obbligatorio per tutti i componenti dell'interfaccia utente. Se un componente non esiste — viene creato prima, poi utilizzato sulla schermata.

La terza misura è l'automazione in CI/CD. Aggiungete un passo di controllo del codice duplicato alla pipeline (PMD CPD, jscpd, SonarQube). Il superamento della soglia comporta un errore di build. Lo sviluppatore non può unire un PR che aumenta il rapporto di copypaste oltre il livello consentito. Questo sposta la responsabilità dalla revisione del codice all'automazione e garantisce che nessun duplicato passi inosservato.

Promuovete una cultura di “un'implementazione — un posto.” Se vedete un'opportunità di riutilizzo — non rimandate il refactoring a dopo. Ogni copypaste lasciato “per dopo” si moltiplica e si trasforma in debito tecnico ingestibile.