¿Qué es el código heredado?
Cultura de ingeniería y práctica de software
El código heredado es código difícil de modificar con seguridad. En la cultura de ingeniería, esto suele significar que el software arrastra historia, suposiciones ocultas y bucles de retroalimentación deficientes, como una cobertura de pruebas escasa o un conocimiento vivo limitado. No significa simplemente "código antiguo". Un sistema de veinte años puede ser fiable y bien comprendido. El código nuevo puede convertirse en código heredado en cuestión de semanas si nadie puede modificarlo con confianza.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Quienes están fuera del mundo del software suelen escuchar "código heredado" e imaginan una pieza de museo: polvorienta pero inofensiva. Los ingenieros suelen referirse a algo más concreto: código en el que cada cambio parece arriesgado porque el comportamiento no es fácil de verificar. La antigüedad del código puede influir, pero la edad por sí sola no es el punto central.
Por eso una definición influyente afirma que el código heredado es código sin pruebas automatizadas. La formulación es deliberadamente directa. Desplaza la atención de las fechas hacia la confianza. Si un equipo no puede comprobar qué hace el código en este momento, incluso un cambio pequeño puede sentirse como operar a ciegas.
Por qué importa
Este término importa porque desplaza la conversación del terreno de la vergüenza al del riesgo. Un sistema antiguo crítico para el negocio no es necesariamente un fracaso. En muchas empresas es lo que sigue facturando a los clientes, procesando pagos, gestionando turnos o manteniendo en marcha una cadena de suministro. Llamarlo heredado es, con frecuencia, menos un insulto que una admisión de que la organización no puede modificarlo a la ligera.
También importa porque "heredado" puede convertirse en una simplificación peligrosa. Los equipos a veces lo usan para decir que algo es viejo, feo, escrito por otra persona, pasado de moda o simplemente molesto. Esos son sentimientos, no diagnósticos. Si se entiende lo que los ingenieros suelen querer decir con código heredado, se está en una posición mucho mejor para evaluar plazos, necesidades de personal y planes de modernización de forma realista.
Cómo funciona
Qué suele significar en la práctica
La fórmula más conocida es "código sin pruebas", y sigue siendo útil porque va directamente al problema del cambio seguro. Las pruebas son verificaciones automatizadas que indican si el comportamiento sigue coincidiendo con lo esperado tras una modificación. Sin ellas, cada edición depende más de la memoria, la comprobación manual y los nervios.
Pero el significado real es algo más amplio. El código se percibe como heredado cuando el conocimiento se ha diluido. Los autores originales se han ido. Las integraciones están mal documentadas. Los bucles de retroalimentación son lentos. Los tiempos de compilación son largos. El comportamiento importante solo se manifiesta en producción. Los registros son escasos. Cada cambio parece tocar varias áreas frágiles a la vez. En ese entorno, incluso el código de aspecto ordenado puede ser código heredado.
Cómo se convierte el código en heredado
Paradójicamente, el éxito es uno de los caminos. El software que sobrevive el tiempo suficiente como para importar acumula regulaciones, particularidades de clientes, APIs de socios, correcciones de errores, soluciones provisionales y limpiezas aplazadas. Con el tiempo, el código empieza a reflejar no solo un diseño, sino años de realidad negociada. Por eso los sistemas antiguos pueden ser a la vez feos y valiosos: han aprendido cosas.
Otro camino es la prisa. Los equipos bajo presión de entrega suelen publicar primero y posponer la capacidad de prueba, la observabilidad o la documentación. Si esos hábitos continúan, el código puede volverse heredado casi de inmediato. Un servicio completamente nuevo sin pruebas, con dependencias enredadas y un solo ingeniero que lo entiende ya es código heredado en embrión.
Algunos sistemas heredados también son difíciles de cambiar porque carecen de buenas costuras. Una costura es un punto donde se puede modificar el comportamiento sin adentrarse directamente en el núcleo del sistema. Si todo está fuertemente acoplado a bases de datos, archivos, servicios externos o estado global, un cambio pequeño puede provocar un radio de impacto muy amplio. Por eso los ingenieros con experiencia dedican tanto tiempo a introducir costuras antes de intentar ediciones importantes.
Cómo trabajan los equipos con código heredado en la práctica
Aquí reside uno de los bucles más frustrantes del software. Para modificar código arriesgado con seguridad, se necesitan pruebas. Pero para añadir pruebas alrededor del código, a menudo hay que modificar el código primero. Michael Feathers llamó a esto el dilema del código heredado, y cualquier ingeniero que haya heredado un sistema frágil lo reconoce de inmediato.
La salida suele ser incremental. Se lee el código existente despacio. Se hacen cambios pequeños y conservadores que introducen una costura, extraen un efecto secundario o aíslan una dependencia. Se construye la verificación automatizada justa para entender el comportamiento actual. Solo entonces se empieza a realizar las mejoras estructurales que la gente imagina cuando dice casualmente "refactorízalo".
Esta es una de las razones por las que la mitología cultural en torno al código heredado suele estar equivocada. Se habla como si el sistema antiguo fuera un pantano y el nuevo fuera a ser un palacio. En realidad, el sistema antiguo puede contener miles de correcciones de errores y reglas de dominio ganadas con esfuerzo que nadie ha escrito completamente. Joel Spolsky señaló con crudeza que el código antiguo no se oxida; a menudo mejora a medida que se descubren y corrigen errores. Eso no lo hace agradable. Sí lo hace peligroso de ignorar.
Leer código heredado también requiere una mentalidad ligeramente distinta a la de leer prosa. Es más lento y más denso. No basta con hojearlo y decidir que se ha entendido. Los equipos se meten en problemas cuando confunden esa incomodidad con la prueba de que el código no vale nada. A veces el código es malo. A veces simplemente es desconocido. La distinción importa mucho.
Ejemplos
Un sistema de nóminas escrito hace años sigue gestionando correctamente los casos extremos más complicados porque ya se ha enfrentado a reglas fiscales reales, excepciones reales y datos históricos reales. Nadie disfruta tocándolo, pero reemplazarlo sin un mapa detallado de esos casos extremos sería imprudente.
Una herramienta de atención al cliente mezcla acceso a la base de datos, renderizado de páginas y reglas de negocio en los mismos archivos. Añadir un campo implica tocar múltiples pantallas y varias rutas de consulta. El problema no es principalmente que el código sea antiguo, sino que el cambio seguro se ha vuelto costoso.
Un servicio llama a una API externa en producción desde el núcleo de la lógica de negocio, por lo que cualquier prueba impacta en una dependencia real y se comporta de forma impredecible. El primer paso útil no es un rediseño completo, sino introducir una costura que permita al equipo sustituir la llamada real por un doble de prueba controlado.
Malentendidos frecuentes
El código heredado no significa simplemente código antiguo. Algunos sistemas antiguos son estables, bien probados y más fáciles de modificar que el experimento de una startup del mes pasado.
Tampoco significa simplemente "código que no escribí yo". El código heredado puede ser excelente. El código nuevo escrito por el propio equipo puede volverse heredado en el momento en que nadie puede explicarlo o verificarlo con seguridad.
Otro mito es que el código heredado debe reescribirse para mejorar. Con frecuencia, el camino más seguro es el endurecimiento gradual: añadir pruebas, introducir costuras, mejorar la observabilidad y remodelar un área a la vez.
Y las pruebas no son una varita mágica. Mejoran la confianza, pero no desenredan automáticamente los límites deficientes, eliminan la duplicación ni borran las reglas de dominio confusas. Hacen posible la mejora deliberada, que es algo distinto.
Riesgos y límites
"Heredado" puede convertirse en una excusa, ya sea para eludir responsabilidades o para insultar a ingenieros anteriores. Los sistemas antiguos suelen reflejar las restricciones de su época: plazos, limitaciones de infraestructura, bibliotecas inmaduras, presión de clientes y decisiones de negocio. Tratarlos como evidencia de un fracaso personal es una actitud infantil que conduce a malas decisiones de modernización.
También existe otro límite. Los equipos no deben romantizar los sistemas heredados simplemente porque sigan funcionando. Si el código es lento de modificar, poco comprendido, con escasas pruebas y operativamente arriesgado, la cortesía no exige negarlo. Respetar el pasado debería hacer el diagnóstico presente más sereno, no más condescendiente.
Qué hacer a continuación
Si se reconoce este patrón en el equipo, conviene dejar de planificar en torno a heroicidades. El trabajo con código heredado mejora cuando los ingenieros disponen de tiempo protegido para añadir pruebas, crear costuras, mejorar los registros, escribir notas breves sobre comportamientos extraños y reducir el tiempo de retroalimentación. Esas actividades parecen indirectas solo si no se entiende lo que cuesta la confianza.
Conviene hacer el conocimiento del dominio portable. Hay que registrar los casos extremos más complicados, conservar ejemplos de comportamiento real y emparejar a los ingenieros más nuevos con quienes conocen los rincones difíciles. El sistema heredado más peligroso suele ser el que vive principalmente en la cabeza de una sola persona.
Por último, hay que tener mucho cuidado con la frase "simplemente reescríbelo". Si lo que realmente existe es un problema de confianza, el primer presupuesto debería destinarse generalmente a comprender y estabilizar el sistema existente, en lugar de declararle la guerra.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Todo el código antiguo es código heredado?
No. La antigüedad puede influir, pero lo heredado tiene que ver principalmente con lo difícil que resulta modificarlo con seguridad y con la confianza que el equipo tiene en su comprensión.
¿Puede el código completamente nuevo ser heredado?
Sí. Si se publica con límites deficientes, poca cobertura de pruebas y un conocimiento compartido escaso, puede volverse heredado casi de inmediato.
¿Por qué se dice que el código heredado es código sin pruebas?
Porque las pruebas son una de las formas más claras de ganar confianza en los cambios. Sin ellas, incluso las ediciones simples pueden ser arriesgadas.
¿El código heredado es siempre código malo?
No. Algunos sistemas heredados son valiosos, fiables y están llenos de conocimiento del mundo real. Pueden seguir siendo difíciles de modificar, lo cual es una cuestión distinta.
¿Qué es una costura en el trabajo con código heredado?
Es un punto donde se puede modificar el comportamiento sin adentrarse en todo el sistema, lo que ayuda a los equipos a aislar dependencias y añadir pruebas con seguridad.
¿Debería la IA facilitar la modernización del código heredado?
La IA puede ayudar a explicar y navegar por el código, pero no elimina el comportamiento oculto, las pruebas ausentes ni el riesgo operativo. Las partes difíciles siguen siendo reales.