Copypaste en el desarrollo de aplicaciones — qué es, por qué es peligroso y cómo evitarlo

¿Qué es el copypaste?

Copypaste (programación por copiar y pegar) es mover código existente a un nuevo lugar con pocos o ningún cambio. El término se usa de forma peyorativa: implica que el desarrollador no está diseñando una solución, sino copiando mecánicamente un bloque ya hecho, a menudo sin entender completamente cómo funciona.

El copypaste se presenta en dos tipos: intencional y accidental. Intencional — cuando un desarrollador copia código deliberadamente con la intención de refactorizarlo después (pero a menudo el plan se abandona). Accidental — cuando la duplicación surge sin ser notada, por ejemplo, dos desarrolladores escriben independientemente la misma lógica para diferentes pantallas.

Según el informe SonarQube State of Clean Code (2025), el código duplicado representa en promedio entre el 12 y el 18 por ciento del volumen total de código en proyectos comerciales. Al mismo tiempo, el costo de corregir un error en código duplicado es 2.5 veces mayor que en código con una implementación única, porque el desarrollador debe encontrar y corregir todas las copias.

La herramienta principal contra el copypaste es el principio DRY (Don't Repeat Yourself). Sin embargo, absolutizar DRY también es peligroso: a veces copiar está justificado cuando dos copias deben evolucionar de forma independiente. Es importante distinguir entre “duplicación accidental” (que debe eliminarse) y “duplicación necesaria” (que debe documentarse).

Por qué es peligroso el copypaste

El primer y más crítico peligro es la propagación de errores. Si el código original tiene un defecto, se copia a todas las nuevas ubicaciones junto con el código. Cuando el defecto se descubre y se corrige en el módulo original, las copias permanecen sin corregir. El desarrollador puede ni siquiera saber que el error existe en cinco archivos diferentes.

El segundo peligro es la evolución desigual. Dos copias del mismo algoritmo acumulan diferentes modificaciones con el tiempo. Una copia añade validación de valores límite, otra cambia el formato de salida. Después de unos meses, se vuelve imposible saber qué versión es la “correcta” y el proyecto pierde consistencia de comportamiento.

El tercer peligro es el aumento del volumen de pruebas. Cada instancia de copypaste requiere sus propias pruebas. Si la lógica común se extrae en una sola función, se puede cubrir con un conjunto de pruebas y reutilizarla. Con la duplicación, cada copia debe probarse por separado — esto multiplica el tiempo de ejecución de CI y el tamaño de la base de pruebas que debe mantenerse.

El cuarto peligro es la ilusión de productividad. El copypaste crea una falsa sensación de velocidad: el desarrollador pega rápidamente el código y ve que la pantalla funciona. Pero esta “velocidad” se convierte en deuda técnica que habrá que pagar con intereses cuando se encuentre un error en el bloque duplicado o se requiera un cambio en la lógica de negocio.

Por qué los desarrolladores copian código

Entender las razones del copypaste ayuda a establecer una prevención adecuada. La mayoría de las veces, los desarrolladores copian código no por pereza, sino por la presión de los plazos, la falta de conocimiento o una arquitectura incómoda.

La primera razón son los plazos ajustados. Cuando hay que crear una pantalla en dos días y ya existe una similar, el desarrollador la copia por completo y cambia solo lo que ve el usuario. No hay tiempo para refactorizar y extraer un componente compartido — el cliente exige resultados. Como resultado, aparece una segunda pantalla con un 80 por ciento de código compartido pero un historial independiente de cambios.

La segunda razón es la falta de una abstracción unificada. Si el proyecto carece de un componente compartido para una tarea típica (por ejemplo, una pantalla de lista con pull-to-refresh), cada desarrollador escribirá su propia implementación o copiará una vecina. Las decisiones arquitectónicas tomadas al inicio del proyecto afectan directamente la cantidad de copypaste futuro.

La tercera razón es el miedo a romper código que funciona. El desarrollador sabe que el módulo existente funciona. Refactorizar para extraer código compartido puede afectar la funcionalidad existente. Si la cobertura de pruebas es baja, el riesgo de romper algo supera el beneficio percibido de la refactorización, y el desarrollador elige el camino seguro — copiar.

Aborde las causas, no los síntomas. Reducir los plazos e introducir la revisión de código no resolverá el problema si el proyecto carece de una base arquitectónica sólida. Invierta tiempo en crear componentes reutilizables desde el principio — es la única manera de reducir la tentación del copypaste en el futuro.

Herramientas de detección de duplicados

La detección de copypaste la realizan analizadores automáticos que comparan fragmentos de código e identifican coincidencias por encima de un umbral determinado. Las mejores herramientas operan a nivel de AST (Árbol de Sintaxis Abstracta) e ignoran el formato, los nombres de variables y los comentarios.

PMD CPD (Copy-Paste Detector) es la herramienta más común para Java, Kotlin, Swift, JavaScript, Python y C++. CPD analiza los tokens del código fuente y encuentra duplicados más largos que un número mínimo de tokens especificado (por defecto 100). Configurar el umbral es clave para obtener resultados de calidad: un umbral demasiado bajo genera muchos falsos positivos (patrones comunes como imports), un umbral demasiado alto omite duplicados reales.

Ejecutar PMD CPD con 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 integra un detector de duplicados directamente en el Quality Gate. La regla Duplicated Blocks (%) muestra el porcentaje de código duplicado. Un umbral del 5 por ciento se considera saludable para proyectos comerciales. Superarlo bloquea la promoción a la rama de lanzamiento. SonarQube también agrupa los duplicados por tipo: coincidencias exactas y copias estructurales (con identificadores renombrados).

Para JavaScript y TypeScript, los duplicados se detectan con ESLint usando el plugin eslint-plugin-sonarjs (la regla no-duplicate-string) y la utilidad jscpd, que soporta más de 150 lenguajes. jscpd es especialmente útil para monorepos: encuentra duplicados entre paquetes, no solo dentro de un único módulo.

Estrategias para refactorizar código duplicado

La refactorización del copypaste se reduce a un principio: extraer la parte común y parametrizar las diferencias. La técnica concreta depende del alcance de la duplicación y del contexto.

El caso más simple es la duplicación dentro de una misma clase (por ejemplo, dos métodos con la misma lógica pero diferentes tipos). La solución es generalizar con genéricos o reutilizar un método con un parámetro de tipo. Si la duplicación abarca varias clases — extraiga el código común a una clase de utilidad o función de extensión.

Un caso más complejo es la duplicación a nivel de pantalla o módulo. Aquí, simplemente extraer una función no ayuda, porque la estructura de la UI, la lógica del ciclo de vida y la vinculación de datos están duplicadas. La solución es crear una clase base de pantalla común o un componente de vista compuesto, y pasar las diferencias mediante parámetros o un protocolo.

// 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)
    }
}

El caso más complejo es la duplicación entre microservicios o bibliotecas. Extraer código compartido puede provocar dependencias circulares o un acoplamiento injustificado. En tales casos, el copypaste puede ser una decisión consciente: dos equipos mantienen servicios independientes, y una biblioteca compartida crea más problemas de los que resuelve. La clave es documentar esa decisión y comprobar regularmente si las copias han divergido lo suficiente como para justificar la unificación.

Prevención del copypaste a nivel de equipo

Prevenir el copypaste es más eficaz que refactorizar código ya duplicado. Las principales medidas preventivas están en la organización del proceso de desarrollo, no en la tecnología.

La primera medida es la revisión de código con enfoque en la duplicación. La lista de verificación de la revisión debe incluir la pregunta: “¿Este PR contiene código que ya existe en el proyecto?” Si el revisor detecta copypaste, bloquea la fusión hasta que se extraiga el componente compartido. Este requisito debe ser parte de la Definición de Hecho del equipo.

La segunda medida es una biblioteca de componentes compartida. Cada patrón de UI que aparece en dos o más pantallas debe extraerse en un módulo común. Cree un módulo compartido en el proyecto y conviértalo en el punto de entrada obligatorio para todos los componentes de UI. Si un componente no existe — primero se crea, luego se usa en la pantalla.

La tercera medida es la automatización en CI/CD. Añada un paso de verificación de código duplicado al pipeline (PMD CPD, jscpd, SonarQube). Superar el umbral resulta en un fallo de compilación. El desarrollador no puede fusionar un PR que aumente la proporción de copypaste por encima del nivel permitido. Esto traslada la responsabilidad de la revisión de código a la automatización y garantiza que ningún duplicado pase desapercibido.

Fomente una cultura de “una implementación — un lugar.” Si ve una oportunidad de reutilización — no posponga la refactorización para más tarde. Cada copypaste dejado “para después” se multiplica y se convierte en deuda técnica inmanejable.