Junk en desarrollo — qué es, por qué es perjudicial el código basura y cómo eliminarlo

¿Qué es el código basura?

Junk (código basura) es un término colectivo para código, configuraciones y dependencias que existen en un proyecto pero no aportan valor funcional. El junk no necesariamente está roto o sin usar — el problema es que su presencia empeora las métricas del proyecto sin una justificación adecuada.

El junk se divide en cuatro categorías. Primera — dependencias redundantes: bibliotecas agregadas para una sola función que podría implementarse con herramientas estándar. Segunda — peso muerto: bloques comentados, TODO sin tickets, métodos vacíos y clases esqueleto. Tercera — soluciones duplicadas: dos bibliotecas que hacen lo mismo (por ejemplo, Gson y Kotlin Serialization en un mismo proyecto). Cuarta — sobreingeniería: capas arquitectónicas que no se usan pero se mantienen “por si acaso.”

Según la investigación de Stripe Engineering Productivity (2025), eliminar el 10 por ciento de junk de un proyecto típico reduce el tiempo de compilación completa en un promedio del 22 por ciento. La razón: cada dependencia extra aumenta el grafo de compilación, cada abstracción vacía requiere tiempo para entenderla, cada bloque comentado distrae la atención.

La principal dificultad en la lucha contra el junk es la ausencia de consecuencias inmediatas. Un proyecto con código basura compila y funciona. Los problemas se acumulan gradualmente: la compilación se ralentiza, la cantidad de dependencias transitivas crece, y al año agregar una nueva funcionalidad lleva el doble de tiempo del que debería.

Dependencias basura y cómo identificarlas

Las dependencias basura son bibliotecas y paquetes agregados a un proyecto que no se usan directamente en el código, o se usan solo para una única función que sería más simple implementar con APIs estándar.

Ejemplos típicos: una biblioteca para procesamiento JSON cuando el proyecto ya usa Kotlin Serialization (dos parseadores es junk); la biblioteca Apache Commons Lang para una sola llamada StringUtils.isEmpty que podría reemplazarse con la extensión isNullOrBlank de Kotlin; una biblioteca de DI usada en un módulo de diez, mientras los otros reciben dependencias manualmente por constructor.

Cada dependencia extra no es solo código adicional en el binario. Aumenta la superficie de ataque para vulnerabilidades: según la GitHub Advisory Database (2025), el 40 por ciento de los CVE críticos en proyectos móviles provienen de dependencias transitivas que los desarrolladores no controlan. Cuantas menos dependencias, menor la superficie de ataque.

Análisis de dependencias de proyectos Android

// View Gradle dependency tree
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Find unused dependencies (Gradle plugin)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Generate unused library report
./gradlew buildHealth

Para iOS, use el comando swift package show-dependencies, que muestra el árbol completo de dependencias. La herramienta Xcode Build Timeline indica cuánto tiempo de compilación agrega cada biblioteca. Si una biblioteca ocupa el 30 por ciento del tiempo de compilación pero se usa en una sola pantalla, es candidata para eliminación o reemplazo.

Para Node.js (React Native), use depcheck — una utilidad que encuentra dependencias no utilizadas en package.json, y npm-check, que además muestra versiones obsoletas. Implemente una regla: cada nueva dependencia debe pasar una revisión de código con una justificación de “por qué no se pueden usar herramientas estándar.”

Importaciones muertas y código comentado

Las importaciones muertas son el tipo más común de junk. No afectan el tiempo de ejecución pero aumentan el tiempo de compilación: el compilador procesa cada importación, incluso las no utilizadas. En proyectos grandes, eliminar importaciones no utilizadas reduce el tiempo de compilación entre un 5 y un 10 por ciento.

Los IDEs modernos resaltan automáticamente las importaciones no utilizadas en gris. Configure la limpieza automática al guardar: en IntelliJ IDEA — Optimize Imports on the fly, en Xcode — Editor > Remove Unused Imports. Agregue una verificación en CI: el linter debe bloquear commits con importaciones no utilizadas.

El código comentado es otro tipo de junk. Los desarrolladores comentan bloques para “no perder” funcionalidad durante la refactorización. Sin embargo, git almacena el historial completo de cambios: cualquier código eliminado puede restaurarse con un solo comando git revert o git log -S . El código comentado en master es una falta de respeto al equipo: cada desarrollador gasta energía mental en la pregunta “¿por qué está comentado esto y cuándo debería descomentarse?”

La regla: no hay código comentado en el repositorio. Si el código no es necesario, elimínelo permanentemente. Si el código es necesario pero está temporalmente desactivado, use un feature toggle con un ticket y una fecha de vencimiento. Comentarios como // TODO: remove after migration — no los deje sin fecha límite. Establezca una fecha y recuérdese con un calendario.

Abstracciones redundantes y sobreingeniería

La sobreingeniería es la creación de capas arquitectónicas que no resuelven problemas actuales pero requieren mantenimiento. Este es uno de los tipos de junk más difíciles porque formalmente el código es “correcto”: sigue SOLID, está cubierto por pruebas y se ajusta a la arquitectura. El problema es que no es necesario.

Un ejemplo clásico es una clase abstracta UseCase con un único método invoke que simplemente llama a un repositorio. Si el UseCase no agrega lógica (caché, reintento, transformación) y solo pasa la llamada, es una entidad extra. Aumenta la navegación en el proyecto: un desarrollador abre el UseCase, ve invoke → repositorio, y lo cierra. Tiempo perdido, beneficio cero.

Otro ejemplo es la parametrización excesiva. Una interfaz genérica con seis parámetros de tipo utilizada en un solo lugar. Cada parámetro de tipo agrega carga cognitiva: al leer el código, hay que mantener seis tipos en mente mientras solo dos se usan realmente. Si una abstracción no se reutiliza, es redundante.

El criterio de corte: si una abstracción no se reutiliza en tres contextos diferentes, elimínela. Una abstracción se justifica cuando realmente resuelve un problema de duplicación, no cuando predice escenarios hipotéticos futuros. YAGNI (You Ain’t Gonna Need It) es el mejor principio para prevenir la sobreingeniería.

Herramientas de auditoría de junk

La auditoría de junk requiere una combinación de análisis estático, análisis de dependencias y revisión manual. Es imposible automatizar completamente la detección de abstracciones redundantes, pero el junk técnico (importaciones muertas, bibliotecas no utilizadas, código comentado) se encuentra con herramientas.

Para una auditoría completa, ejecute buildHealth (Android) o depcheck (Node.js) una vez por sprint. Cree un panel en CI que muestre la tendencia de la cantidad de dependencias a través de los sprints. Si la cantidad crece pero la funcionalidad no crece proporcionalmente, el equipo está acumulando junk.

Preste atención a las clases duplicadas — un error que ocurre cuando dos bibliotecas contienen la misma clase. Esto no solo es junk sino también una fuente directa de conflictos de compilación. En Gradle, estos conflictos se resuelven mediante force o exclude, pero cada resolución es una señal de que una de las bibliotecas sobra.

Proceso de limpieza regular del proyecto

La limpieza de junk no es una acción única sino un proceso regular. Sin un procedimiento, el junk regresa en dos o tres sprints. La mejor práctica es asignar entre el 10 y el 15 por ciento de la capacidad de cada sprint a la limpieza técnica, incluyendo la auditoría de junk.

El proceso consta de cuatro pasos. Primero — diagnóstico: ejecutar herramientas, obtener un informe, priorizar. Prioridad alta: dependencias con CVE conocidos y bibliotecas duplicadas. Prioridad media: importaciones muertas y código comentado. Prioridad baja: abstracciones redundantes (requieren análisis manual).

Segundo — limpieza: eliminar dependencias muertas, reemplazar bibliotecas duplicadas por una, borrar código comentado. Cada cambio debe ser un commit separado con un mensaje claro: “remove unused dependency: gson (replaced by kotlinx.serialization)”, “delete commented code in LoginViewModel.”

Tercero — verificación: compilar el proyecto, ejecutar pruebas, verificar la UI. Si las pruebas pasan después de eliminar una dependencia, la dependencia realmente era innecesaria. Si las pruebas fallan, hay una referencia oculta que el analizador estático no detectó.

Cuarto — prevención: actualizar la lista de verificación de code review, agregar una regla “sin nueva dependencia sin justificación” a la Definition of Done, configurar verificaciones automáticas en CI. La prevención es la única forma de evitar que el junk se acumule nuevamente.