tag style img div attribute legacy

legacy - style - img html title



¿Qué hace que el código sea heredado? (19)

He escuchado que muchos desarrolladores se refieren al código como "legado". La mayoría de las veces es un código que ha sido escrito por alguien que ya no trabaja en el proyecto. ¿Qué es lo que hace código, código heredado?

Actualice en respuesta a: "Algo heredado de un antecesor o predecesor o del pasado" http://www.thefreedictionary.com/legacy . Claramente querías saber algo más. ¿Podría aclarar o ampliar su pregunta? S.Lott

Estoy buscando los síntomas del código heredado que lo hacen inutilizable o una pesadilla para trabajar. ¿Cuándo es mejor tirarlo? En mi opinión, el código debería descartarse más a menudo y la reinvención de la rueda es una parte valiosa del desarrollo. El ideal académico de no reinventar la rueda es agradable, pero no es muy práctico.

Por otro lado, obviamente hay un código heredado que vale la pena conservar.


¿Qué es lo que hace código, código heredado?

Al igual que con el legado simple, cuando el autor está muerto o desaparecido, usted como heredero obtiene todo o parte de su código.

Derrames algunas lágrimas y trata de descubrir qué hacer con toda esta basura.


Al usar hardware, software, API, idiomas, tecnologías o funciones que ya no son compatibles o que han sido reemplazados, generalmente se combinan con poca o ninguna posibilidad de reemplazar ese código, en su lugar, utilizándolo hasta que el sistema muera.


Ciertamente, el código heredado es cualquier código, marco, api, de otro software que ya no sea "genial". Por ejemplo, COBOL es unánimemente considerado como legado mientras que APL no lo es. Ahora también se puede argumentar que COBOL se considera herencia y APL no porque tenga aproximadamente 1 millón de veces la base de instalación como APL. Sin embargo, si dices que necesitas trabajar con el código APL, la respuesta no sería "oh no, esas cosas heredadas", sino "oh Dios mío, supongo que no harás nada durante el próximo siglo" ¿ves la diferencia?


Cualquier código con soporte (o documentación) faltante. Ya sea:

  • comentarios en línea
  • documentación técnica
  • documentación hablada (la persona que la escribió)
  • pruebas unitarias que documentan el funcionamiento del código

De acuerdo con Michael Feathers, el autor del excelente Código de Trabajo Efectivo con Legado , el código heredado es un código que no tiene pruebas. Cuando no hay forma de saber qué se rompe cuando cambia este código.

Lo principal que distingue el código heredado del código no heredado son las pruebas, o más bien la falta de pruebas. Podemos tener una idea de esto con un pequeño experimento mental: ¿qué tan fácil sería modificar su base de código si pudiera afectar, si pudiera decirle cuándo cometió un error? Sería bastante fácil, ¿no? La mayor parte del miedo involucrado en hacer cambios a grandes bases de código es el miedo a introducir errores sutiles; miedo a cambiar las cosas inadvertidamente. Con las pruebas, puedes mejorar las cosas con impunidad. Para mí, la diferencia es tan crítica que supera cualquier otra distinción. Con las pruebas, puedes mejorar las cosas. Sin ellos, simplemente no se sabe si las cosas están mejorando o empeorando.


El código (o cualquier otra cosa, en realidad) se convierte en "legado" cuando ha sido reemplazado por algo más nuevo / mejor, y aún así sigue usándose y manteniéndose vivo "en la naturaleza".


Es un término muy general (y frecuentemente abusado) pero cualquiera de las siguientes sería razones legítimas para llamar a un legado de aplicación:

  1. La base de código se basa en un idioma / plataforma que no está totalmente respaldada por el fabricante del producto original (a menudo dicho fabricante ha cerrado).

  2. (Realmente, 1a) La base de código o la plataforma en la que está construida es tan antigua que conseguir desarrolladores calificados o experimentados para el sistema es difícil y costoso.

  3. La aplicación admite algunos aspectos del negocio que ya no se cultivan activamente y para los cuales las alteraciones son extremadamente raras, normalmente para solucionarlo si algo completamente inesperado cambia a su alrededor (el ejemplo canónico es el problema del Y2K) o si algunas fuerzas de regulación / presión externa eso. Dado que ambas razones son apremiantes y normalmente inevitables, pero no se ha producido un desarrollo significativo en el proyecto, es probable que las personas asignadas para tratar con esto no estén familiarizadas con el sistema (y sus conductas y complejidades acumuladas). En estos casos, esta sería a menudo una razón para aumentar el riesgo percibido y planificado asociado con el proyecto.

  4. El sistema ha sido / o está siendo reemplazado por otro. Como tal, el sistema puede usarse por mucho menos de lo previsto originalmente, o tal vez solo como un medio para ver datos históricos.


Legacy generalmente se refiere a un código que ya no se está desarrollando, lo que significa que si lo usa, debe usarlo en sus términos originales, no puede simplemente editarlo para que sea compatible con la apariencia del mundo actual. Por ejemplo, el código heredado debe ejecutarse en hardware que puede que no exista hoy o que ya no sea compatible.


Michael Feathers tiene una definición interesante en su libro Working Effectively with Legacy Code. Según él, el código heredado es código sin pruebas automatizadas.


Para mí, el código heredado es código que se escribió antes de algún cambio de paradigma. Todavía puede estar muy en uso, pero está en proceso de ser refactorizado para ponerlo en línea.
Por ejemplo, un viejo código de procedimiento dando vueltas en un sistema OO por lo demás.


Preservar el código heredado no es tanto un ideal académico como mantener el código que funciona, no importa cuán pobre sea. En muchas situaciones empresariales conservadoras, eso se consideraría más práctico que tirarlo y comenzar de cero. Mejor malo conocido...


Un colega me dijo una vez que el código heredado era cualquier código que usted no había escrito usted mismo.

Podría decirse que es simplemente un término peyorativo para el código que ya no nos gusta por el motivo que sea (generalmente porque no es bueno ni está de moda, pero funciona).

La brigada TDD podría sugerir que cualquier código sin pruebas es código heredado.


El código heredado es un código fuente que se relaciona con un sistema operativo ya no compatible o fabricado u otra tecnología informática.



Considero que el código es "heredado" si se cumple alguna o todas de las siguientes condiciones:

  • Fue escrito usando un lenguaje o metodología que es una generación detrás de los estándares actuales
  • El código es un completo desastre sin planificación o diseño detrás de él
  • Está escrito en idiomas obsoletos y en un estilo obsoleto, no orientado a objetos
  • Es difícil encontrar desarrolladores que conozcan el idioma porque es muy antiguo

A diferencia de algunas de las otras opiniones aquí, he visto muchas aplicaciones modernas que funcionan decentemente sin pruebas unitarias. Las pruebas unitarias todavía no se han puesto al día con todos. Tal vez dentro de diez años la próxima generación de programadores examinará nuestras aplicaciones actuales y las considerará "heredadas" por no contener pruebas unitarias, del mismo modo que considero que las aplicaciones no orientadas a objetos son heredadas.

Si es necesario realizar pocos cambios en una base de código heredada, es mejor simplemente dejarla tal como está y continuar con el flujo. Si la aplicación necesita cambios de funcionalidad drásticos, una revisión de la GUI y / o no puede encontrar a nadie que conozca el lenguaje de programación, es hora de tirar y comenzar de nuevo. Sin embargo, una advertencia: la reescritura desde cero puede consumir mucho tiempo y es difícil saber si ha replicado todas las funciones. Probablemente desee tener casos de prueba y pruebas unitarias escritas para la aplicación heredada y la nueva aplicación.


El código heredado es cualquier cosa escrita hace más de un mes :-)


A menudo es cualquier código que no está escrito en el lenguaje de programación de moda du jour, y estoy medio en broma.


El código heredado es un código que es doloroso / costoso para mantenerse al día con los requisitos cambiantes.

Hay dos formas en que esto puede suceder:

  1. El código no es adecuado para el cambio
  2. La semántica del código se ha cambiado a silicio

1) es el más fácil de los dos para reconocer. Es un software que tiene límites fundamentales que lo incapacita para mantenerse al día con el ecosistema que lo rodea. Por ejemplo, un sistema construido alrededor del algoritmo O (n ^ 2) no escalará más allá de cierto punto y se debe volver a escribir si los requisitos se mueven en esa dirección. Otro ejemplo es el código que utiliza bibliotecas que no son compatibles con las últimas versiones del sistema operativo.

2) Es más difícil de reconocer, pero todos los códigos de este tipo comparten la característica de que las personas tienen miedo de cambiarlo. Esto podría ser porque estaba mal escrito / documentado para empezar, porque no se ha probado, o porque no es trivial y los autores originales que lo entendieron abandonaron el equipo.

Los caracteres ASCII / Unicode que comprenden el código de vida tienen un significado semántico, el "por qué", "qué es" y, hasta cierto punto, el "cómo" en las mentes de las personas asociadas con él. El código heredado no es de propiedad propia o los propietarios no tienen un significado asociado con grandes porciones del mismo. Una vez que esto sucede (y podría suceder al día siguiente con un código realmente mal escrito), para cambiar este código, alguien debe aprenderlo y entenderlo. Este proceso es una fracción significativa del tiempo que lleva escribirlo en primer lugar.


Nadie va a leer esto, pero siento que las otras respuestas no lo hacen del todo bien:

  1. Tiene valor, si no fuera útil, hubiera sido descartado hace mucho tiempo
  2. Es difícil razonar porque cualquiera de
    1. La falta de documentación
    2. El autor original no puede ser encontrado u olvidado (¡sí, 2 meses después tu código también puede ser código heredado!),
    3. La falta de pruebas o sistema de tipos
    4. No sigue las prácticas modernas (es decir, no hay contexto para aferrarse también)
  3. Hay un requisito para cambiarlo o ampliarlo. Si no hay un requisito para cambiarlo, no es un código heredado ya que a nadie le importa. Hace su trabajo y no hay nadie alrededor para llamarlo código heredado.