Cómo Detectar y Eliminar Código No Utilizado: Guía Completa para Equipos

Estrategias prácticas para limpiar tu base de código y mejorar el rendimiento.

Cómo Detectar y Eliminar Código No Utilizado: Guía Completa para Equipos

Por Jose Luis Rueda · 13 min lectura · 2026-07-28

Todo proyecto de software acumula grasa con el tiempo. Variables que declaraste hace tres sprints y nunca llamaste. Funciones que quedaron huérfanas tras un refactor apresurado. Dependencias enteras que instalaste para probar una librería y olvidaste remover. Este lastre, conocido como código no utilizado o dead code, no solo hincha repositorios: ralentiza las compilaciones, complica la incorporación de nuevos desarrolladores y, en aplicaciones web, castiga el rendimiento de los usuarios finales.

El problema rara vez se aborda por una razón simple: el código muerto no grita. No rompe tests ni lanza excepciones. Simplemente ocupa espacio y genera fricción, como un polvo invisible que se deposita sobre las partes móviles de un motor. Las revisiones manuales son poco fiables y costosas, por lo que los equipos profesionales necesitan automatizar la detección con herramientas de análisis estático, técnicas de tree shaking e integraciones en el pipeline de CI/CD.

En este artículo desglosaremos por qué el código no utilizado es más caro de lo que parece, cómo detectarlo con precisión en distintos lenguajes y stacks, y qué prácticas adoptar para que tu base de código se mantenga esbelta sin sacrificar agilidad.

La epidemia silenciosa del código muerto

El código no utilizado adopta varias formas. Están las variables no referenciadas, aquellas que se inicializan pero jamás se leen. Las funciones y métodos definidos en algún rincón del proyecto y nunca invocados. Las importaciones de módulos enteros que no se aprovechan. Y las rutas o endpoints de una API que el frontend dejó de consumir hace meses. En proyectos grandes, estas piezas sueltas pueden representar entre un 10% y un 30% del código total, según estudios empíricos de equipos que han hecho limpiezas profundas.

Cada línea muerta es una pequeña mentira. El desarrollador que la lee asume que cumple un propósito y dedica minutos a entenderla. Multiplica ese esfuerzo por un equipo de 15 ingenieros y por dos años de mantenimiento, y el costo cognitivo se dispara. No es solo una cuestión de estética: el código no utilizado erosiona la velocidad de desarrollo y la confianza en el sistema.

Impacto real en el rendimiento y costos

En el backend, los microservicios que arrastran dependencias huérfanas consumen más memoria al iniciar y alargan el tiempo de despliegue. En frontend, cada kilobyte de JavaScript o CSS que el navegador debe descargar, parsear y ejecutar penaliza métricas clave como First Contentful Paint y Time to Interactive. Un bundle hinchado puede degradar la puntuación de Lighthouse y, en consecuencia, el SEO de una aplicación web. Google penaliza los sitios lentos, sobre todo en móviles.

El costo financiero también aparece en la factura de cloud. Si usas funciones serverless, pagas por tiempo de ejecución y memoria. Cargar bibliotecas no utilizadas incrementa el cold start y, por tanto, el costo por invocación. En builds de CI/CD, el tiempo extra que toma compilar y empaquetar código muerto se traduce en minutos que, al final del mes, suman horas de cómputo facturables.

Señales de alerta: cómo identificar código obsoleto

Antes de recurrir a herramientas automáticas, hay síntomas que delatan la presencia de dead code. El primero es el tamaño del bundle de producción: si tu aplicación React pesa 2 MB pero la funcionalidad visible es modesta, algo está sobrando. Otro indicio es la antigüedad de los archivos. Un módulo que no recibe commits desde hace un año y cuyo autor original ya no está en la empresa es un candidato natural para la eliminación.

Las coberturas de testing también pueden orientarte. Si usas herramientas como Istanbul o JaCoCo, los reportes de cobertura muestran líneas y ramas que no se ejecutan jamás. Ojo, una línea no cubierta no siempre es código muerto, puede ser un caso límite sin test, pero el análisis combinado con otras métricas reduce falsos positivos.

Análisis estático: tu primera línea de defensa

Los analizadores estáticos examinan el código fuente sin ejecutarlo y son capaces de detectar variables y funciones no utilizadas con alta precisión. Para JavaScript y TypeScript, ESLint ofrece la regla no-unused-vars que, correctamente configurada, señala cualquier declaración sin referencia. Si añades el plugin @typescript-eslint, la regla se vuelve aún más afinada, distinguiendo entre variables privadas y públicas en clases.

En Python, Flake8 con el plugin flake8-unused-arguments o Pylint pueden reportar imports y funciones sin uso. En Java, SonarQube y IntelliJ IDEA integran inspecciones que marcan métodos privados nunca llamados. La clave está en integrar estas reglas desde el inicio del proyecto y no activarlas de golpe sobre un código heredado con miles de warnings, porque eso genera ruido y desmotiva al equipo. Un enfoque escalonado funciona mejor: habilitar las reglas para nuevos archivos y, gradualmente, sanear los existentes.

Herramientas imprescindibles por lenguaje

Cada ecosistema cuenta con herramientas especializadas que van más allá del análisis estático básico. Aquí tienes una selección que cubre los stacks más comunes en el mercado hispano:

Ninguna herramienta es perfecta. Los falsos positivos existen, sobre todo en lenguajes dinámicos donde la reflexión o la metaprogramación pueden ocultar usos. Por eso la validación humana sigue siendo necesaria al revisar los resultados.

Técnicas avanzadas: tree shaking y eliminación de dependencias

El tree shaking es una técnica de optimización que los empaquetadores modernos (webpack, Rollup, esbuild) realizan sobre código ES6. Consiste en analizar el grafo de imports y exports para excluir del bundle final cualquier export que no sea importado por otro módulo. El requisito es usar módulos ES (ESM), porque CommonJS no permite el análisis estático de dependencias. Si tu aplicación todavía usa require, migrar a import es el primer paso para desbloquear el tree shaking.

Para que el tree shaking sea efectivo, debes asegurarte de que tu código no produzca efectos secundarios (side effects). Si un módulo modifica el window global o extiende prototipos, el empaquetador no puede eliminar ese código de forma segura porque no sabe si ese efecto es necesario. Marcar los archivos libres de efectos secundarios en package.json ('sideEffects': false) es una práctica recomendada.

En el ecosistema de React, el tree shaking puede fallar si importas componentes con patrones como import * as MUI from '@mui/material'. La alternativa es usar imports nombrados o babel-plugin-import para solo cargar lo que necesitas. Una auditoría rápida con source-map-explorer o webpack-bundle-analyzer mostrará gráficamente qué módulos inflan tu bundle.

Integrando la detección en el flujo de CI/CD

Detectar código muerto una vez al año no sirve. Para mantener el repositorio limpio, el análisis debe ser continuo. La estrategia más efectiva consiste en añadir un paso en el pipeline de CI que ejecute herramientas como knip, depcheck o una auditoría de ESLint con la regla no-unused-vars en nivel error. Si se detectan nuevos casos, el build se rompe. Así, el código muerto se trata con la misma seriedad que un test fallido.

El umbral de tolerancia puede graduarse. En una primera fase, el pipeline solo emite una advertencia por Slack y no bloquea. A medida que el equipo limpia el código heredado, se eleva la exigencia. En entornos como GitHub Actions, puedes generar un comentario en el PR con la lista de imports no utilizados, lo que permite al revisor decidir caso por caso.

Las herramientas de AI generativa también están empezando a asistir en este terreno. Por ejemplo, asistentes como HolaGPT pueden analizar fragmentos de código durante las revisiones y sugerir eliminaciones seguras, aprendiendo de los patrones del proyecto sin reemplazar el juicio del desarrollador.

Casos prácticos: antes y después de la limpieza

Considera un proyecto React con Redux, una docena de sagas y 40 acciones definidas. Tras ejecutar knip, el equipo descubrió que 7 acciones nunca eran despachadas y 3 sagas estaban completamente aisladas. Al eliminar ese código, el bundle de producción se redujo un 12% y el tiempo de compilación bajó 8 segundos. Además, la refactorización posterior fue más sencilla porque las dependencias estaban más claras.

En otro caso, una API en Node.js que usaba Express mantenía 5 middlewares de autenticación heredados de un proveedor antiguo. Con depcheck se detectó que dos de ellos ya no se montaban en ninguna ruta. Removerlos no solo liberó memoria, sino que eliminó una vulnerabilidad de seguridad porque el middleware obsoleto tenía una dependencia con un CVE conocido.

Estos ejemplos muestran que el impacto va más allá del rendimiento: la seguridad, la mantenibilidad y la velocidad del equipo mejoran de forma directa.

Conclusión: una cultura de código limpio

Identificar código no utilizado no es una tarea de una sola vez. Requiere herramientas automatizadas, integración en el flujo diario y un cambio cultural donde cada desarrollador se sienta responsable de lo que deja en el repositorio. Las variables muertas, las funciones huérfanas y las dependencias infladas no son crímenes, pero tolerarlas sale caro.

Empieza hoy. Elige una herramienta de esta guía, actívala en tu proyecto y rompe el build la próxima vez que aparezca una declaración sin uso. En menos de un sprint notarás la diferencia.