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

StackOverflow https://stackoverflow.com/questions/479596

  •  20-08-2019
  •  | 
  •  

Pregunta

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

Actualización en respuesta a: " Algo transmitido de un antepasado o un 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 hacen que sea inutilizable o una pesadilla para trabajar. ¿Cuándo es mejor tirarlo? Es mi opinión que el código debe desecharse con más frecuencia y que reinventar 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 mantener.

¿Fue útil?

Solución

Al usar hardware, software, API, idiomas, tecnologías o características que ya no son compatibles o han sido reemplazadas, generalmente combinadas con poca o ninguna posibilidad de reemplazar ese código, en lugar de usarlo hasta que el sistema muera.

Otros consejos

  

¿Qué es lo que hace que el código, el 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.

Derramas algunas lágrimas e intentas averiguar qué hacer con toda esta basura.

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.

Es un término muy general (y a menudo abusado), pero cualquiera de los siguientes serían motivos legítimos para llamar un legado de aplicación:

  1. La base del código se basa en un lenguaje / plataforma que no es totalmente compatible con el fabricante del producto original (a menudo dicho fabricante ha cerrado).

  2. (realmente 1a) La base de código o 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 algún aspecto del negocio que ya no se desarrolla activamente y cuyas alteraciones son extremadamente raras, normalmente para solucionarlo si algo completamente inesperado cambia a su alrededor (el ejemplo canónico es el problema Y2K) o si alguna regulación / presión externa lo fuerza. 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 lidiar con esto no estén familiarizadas con el sistema (y sus comportamientos y complejidades acumulados). En estos casos, esto a menudo sería motivo para aumentar el riesgo percibido y planificado asociado con el proyecto.

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

Legacy generalmente se refiere al 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 respaldar la forma en que se ve el mundo hoy en día. Por ejemplo, el código heredado debe ejecutarse en hardware que puede no existir hoy, o que ya no es compatible.

Según Michael Feathers, autor del excelente Trabajando eficazmente con código heredado , el código heredado es un código que no tiene pruebas. Cuando no hay forma de saber qué se rompe cuando este código cambia.

  

Lo principal que distingue   el código heredado del código no heredado es   pruebas, o más bien la falta de pruebas. Nosotros   puede tener una idea de esto con un poco   experimento mental: qué tan fácil sería   ser para modificar su base de código si   podría retroceder, si pudiera decirte   cuando cometiste un error? Podría ser   bastante fácil, ¿no? La mayoría de   miedo involucrado en hacer cambios a   grandes bases de código es miedo a   introduciendo errores sutiles; miedo de   cambiando cosas inadvertidamente. Con   pruebas, puedes mejorar las cosas con   impunidad. Para mí, la diferencia es tan   crítico, abruma a cualquier otro   distinción. Con las pruebas, puedes hacer   cosas mejor Sin ellos, tu solo   don & # 8217; no sé si las cosas se están poniendo   mejor o peor.

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

Podría decirse que es solo un término peyorativo para el código que ya no nos gusta por la razón que sea (generalmente porque no es genial 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 que ya no es compatible o fabricado o otra tecnología informática.

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

  1. Tiene valor, si no fuera útil, se habría tirado hace mucho tiempo
  2. Es difícil razonar porque cualquiera de
    1. Falta de documentación,
    2. El autor original no se puede encontrar u olvidar (sí, ¡2 meses después, su código también puede ser código heredado!),
    3. 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 extenderlo. Si no hay un requisito para cambiarlo, no es código heredado ya que a nadie le importa. Hace lo suyo y no hay nadie para llamarlo código heredado.

http://en.wikipedia.org/wiki/Legacy_code

" El código heredado es el código fuente que se relaciona con un "

Falta cualquier código con soporte (o documentación). 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

Para mí, el código heredado es un código que se escribió antes de algún cambio de paradigma. Puede que todavía esté en uso, pero se está refactorizando para alinearlo.
p.ej. Código de procedimiento antiguo dando vueltas en un sistema de otro modo OO.

El código (o cualquier otra cosa, realmente) se convierte en " legacy " cuando ha sido reemplazado por algo más nuevo / mejor, y sin embargo, a pesar de esto, todavía se usa y se mantiene vivo " in the wild " ;.

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

El código heredado es un código que es doloroso / costoso de mantener actualizado con los requisitos cambiantes.

Hay dos formas en que esto puede suceder:

  1. El código no es apto 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 hacen incapaz de 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 debe reescribirse si los requisitos se mueven en esa dirección. Otro ejemplo es el código que usa bibliotecas que no son compatibles con las últimas versiones del sistema operativo.

2) Es más difícil de reconocer, pero todo código de este tipo comparte la característica de que la gente tiene miedo de cambiarlo. Para empezar, esto podría deberse a que estaba mal escrito / documentado, 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 vivo tienen un significado semántico, el " why's " ;, " What's " y hasta cierto punto el & "; cómo está &" en las mentes de las personas asociadas con él. El código heredado no es propiedad o los propietarios no tienen un significado asociado con grandes porciones de él. 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 comprenderlo. Este proceso es una fracción significativa del tiempo que lleva escribirlo en primer lugar.

El día que tiene miedo de refactorizar su código es el día en que su código se ha convertido en heredado.

Considero el código " legacy " si alguna o todas las siguientes condiciones aplican:

  • Fue escrito usando un lenguaje o metodología que está una generación por detrás de los estándares actuales
  • El código es un completo desastre sin planificación o diseño detrás
  • 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 aún no se han contagiado con todos. Quizás dentro de diez años la próxima generación de programadores analizará nuestras aplicaciones actuales y las considerará & Quot; legacy & Quot; por no contener pruebas unitarias, así como 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 como está e ir con la corriente. Si la aplicación necesita cambios drásticos en la funcionalidad, una revisión de la GUI y / o no puede encontrar a nadie que conozca el lenguaje de programación, es hora de descartar y comenzar de nuevo. Sin embargo, una advertencia: reescribir desde cero puede llevar mucho tiempo y es difícil saber si ha replicado toda la funcionalidad. Probablemente desee tener casos de prueba y pruebas unitarias escritas para la aplicación heredada y la nueva aplicación.

Honestamente, el código heredado es cualquier código, marco, api, de otra construcción de software que no sea & "; genial &"; nunca más. Por ejemplo, COBOL se considera unánimemente como legado, mientras que APL no. Ahora también se puede argumentar que COBOL se considera heredado y APL no porque tiene aproximadamente 1 millón de veces la base de instalación como APL. Sin embargo, si dice que necesita trabajar en el código APL, la respuesta no sería & "; Oh no, ese material heredado &"; sino más bien & "; ¡Dios mío, supongo que no harás nada durante el próximo siglo &"; ¿Ves la diferencia?

Este es un término general que se utiliza con bastante frecuencia (y de manera bastante genérica) en el ecosistema de software.

Bueno, me gusta pensar que el código heredado es código heredado . Esto es simplemente código que fue escrito en el pasado. En la mayoría de los casos, el código heredado no sigue las prácticas nuevas / actuales y a menudo se considera arcaico.

El código heredado es algo escrito hace más de un mes :-)

A menudo es cualquier código que no está escrito en el lenguaje de scripting de moda del día, y estoy bromeando a medias.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top