¿Cuándo es el código "heredado"? [cerrado]


63

Todos lo hemos hecho, hemos etiquetado algunos códigos (a menudo cosas que hemos heredado) como "heredados"? Pero todavía se usa en los sistemas de producción, entonces ¿es realmente un legado? ¿Y qué lo hace legado? ¿Deberíamos evitar esta etiqueta injustificada de código que funciona perfectamente? donde el etiquetado es una pura conveniencia que nos permite impulsar nuevas cosas y mantener a la alta gerencia agradable y feliz?


Resumen de respuestas

Mirando las respuestas veo cuatro temas generales. Aquí es como veo el desglose:

  1. Cualquier código que se haya entregado: 6
  2. Sistemas muertos: 2.5
  3. Sin pruebas unitarias: 2
  4. Los desarrolladores no están alrededor: 1.5


1
Es un código heredado tan pronto como se entrega y funciona.
Martin Beckett

23
es código heredado si no lo escribiste ;-)
Steven A. Lowe

20
Es un código heredado si todos los que lo escribieron están retirados o muertos, y si los que continúan manteniéndolo desearían estarlo. De lo contrario, solo se llama la base de código existente.
antipático el

3
@ StevenA.Lowe, dado el tiempo suficiente, es un código heredado, incluso si lo escribí.
Kyralessa

Respuestas:


43

Soy bastante parcial al resumen de Wikipedia :

Un sistema heredado es un método, tecnología, sistema informático o programa de aplicación antiguo que se sigue utilizando, generalmente porque todavía funciona para las necesidades de los usuarios, a pesar de que ahora hay disponibles tecnologías más nuevas o métodos más eficientes para realizar una tarea.

Mucho de lo que otras personas describen en sus respuestas son razones por las cuales el código se convierte en "legado". Pero la pregunta esencial en sí misma es esta:

Pero todavía se usa en los sistemas de producción, entonces ¿es realmente un legado? ¿Y qué lo hace legado?

El hecho de que todavía se use en producción es precisamente lo que lo hace legado . Si el código no funciona correctamente, o ya no se usa en producción, entonces ese código está "roto" o "retirado", respectivamente. Legacy significa que todavía está en uso y funciona bien, pero incorpora diseños o técnicas que ya no son de uso común.

Cualquier código o sistema que (a) le gustaría actualizar / actualizar, pero no puede, o (b) todavía está en medio de la actualización, es un sistema heredado. Esto no significa refactorización o limpieza general del código, significa cambios significativos en el diseño, posiblemente utilizando un nuevo marco o incluso una nueva plataforma.

Existen varias razones por las cuales los sistemas o el código pueden convertirse en heredados:

  • Falta de mantenimiento regular o software podrido . Claramente, si la aplicación no se mantiene regularmente, no seguirá el ritmo de los cambios importantes en el mundo del software. Esto puede deberse a una simple negligencia o puede ser una elección deliberada basada en prioridades comerciales o restricciones presupuestarias.

  • Falta de pruebas. Otra respuesta hace referencia a la afirmación hiperbólica de un autor popular de que cualquier código no cubierto por las pruebas es código heredado. Esto realmente no es una definición precisa, pero es una posible causa raíz; sin buenas pruebas (automatizadas o manuales), los desarrolladores se vuelven tímidos y temen hacer cambios importantes porque se preocupan por romper algo, lo que lleva a la "putrefacción del software" anterior.

  • Rev-lock, un factor que a menudo se pasa por alto y que es particularmente insidioso en proyectos que usan grandes bibliotecas o marcos de código abierto (aunque también lo he visto con herramientas comerciales). A menudo se realizará una personalización importante en el marco / biblioteca, lo que hará que una actualización sea prohibitivamente difícil o costosa. Por lo tanto, el sistema se vuelve heredado porque se ejecuta en una plataforma más antigua (y posiblemente ya no es compatible).

  • El código fuente ya no está disponible, lo que significa que el sistema solo se puede agregar, nunca cambiar. Dado que estos sistemas tienen que reescribirse para actualizarse, en lugar de revisarse de forma gradual / iterativa, muchas empresas no se molestarán.

Cualquier cosa que ralentice o detenga las actualizaciones de una base de código puede hacer que esa base de código se vuelva heredada.

Ahora la pregunta separada, no declarada pero implícita es, ¿qué tiene de malo el código heredado? A menudo se usa como un término peyorativo, de ahí la pregunta:

¿Deberíamos evitar este etiquetado injustificado de código que funciona perfectamente?

Y la respuesta es no, no deberíamos; el etiquetado está garantizado y el término en sí implica claramente un código funcional. El punto no es que sea ​​función, sino cómo está funcionando.

En algunos casos no hay nada de malo con el código heredado. No es una mala palabra. Los códigos / sistemas heredados no son malvados. Acaban de recoger algo de polvo, a veces un poco, a veces mucho.

El legado se vuelve obsoleto cuando el sistema ya no puede atender (todas) las necesidades del cliente. Esa etiqueta es una de la que debemos tener cuidado. De lo contrario, es simplemente una ecuación de costo / beneficio; si el costo de la actualización sería menor que el costo de sus beneficios (incluidos los costos de mantenimiento futuros más bajos), entonces actualice, de lo contrario, déjelo en paz. No es necesario escupir la palabra "legado" en el mismo tono que normalmente reserva para "auditoría fiscal". Es una situación perfectamente aceptable para estar.


Dicho esto, la auditoría fiscal también debería ser una situación perfectamente aceptable.
Florian Margaine

Yo diría: Sistema que ya no puede ser escalable con su Pila de Tecnología existente.
Ramiz Uddin

40

Por lo general, significa que está escrito en un idioma o basado en un sistema en el que normalmente no se realiza un nuevo desarrollo.

Por ejemplo, la mayoría de los lugares no escriben nuevos programas en Cobol. Sin embargo, una gran parte de su negocio puede ejecutarse en aplicaciones escritas en Cobol. Por lo tanto, esas aplicaciones están etiquetadas como "Legacy".


Estoy de acuerdo con esta respuesta más. Legacy se trata más de quedarse atrapado en una plataforma obsoleta que de ser un código molesto (pero moderno) que no desea admitir. El código heredado a menudo es bastante bueno (de lo contrario, a nadie le importaría si lo dejara atrás), pero generalmente está conectado a hardware obsoleto e idiomas / bibliotecas / bases de datos anticuados / etc.
Satanicpuppy

3
@Satanicpuppy: simplemente no puedo estar de acuerdo, he tratado (por ejemplo) algo de Java que definitivamente no estaba vinculado a ningún hardware, biblioteca o base de datos en particular, pero era tan "heredado" como lo era (y fue reescrito en Java, por lo que el idioma tampoco era el problema). También me ocupé de un código que estaba vinculado a un hardware específico, pero que apenas alcanzaba la categoría de "legado".
Jerry Coffin

44
@jerry: Entonces, ¿qué lo hizo legado? Legacy no es sinónimo de "malo".
Satanicpuppy

1
En el caso en el que estoy pensando, era un sistema distribuido bastante grande (construido alrededor de BEA Tuxedo). El diseño parecía basado en escenarios de libros de texto que pretenden enseñar acerca de la sincronización maximizando la cantidad de veces / lugares que se necesita la sincronización. Eso (más o menos) tiene sentido para un libro de texto, pero es horrible para diseños reales. Era lo suficientemente grande como para que incluso diseñar un reemplazo fuera un proyecto de varios años. El reemplazo tuvo que hacerse en fases sin tiempo de inactividad, porque el sistema era completamente necesario para el negocio.
Jerry Coffin

1
@Cawas: Me parece que la respuesta de @ Chad se aplicaría cuando / si el nuevo sistema se hiciera en un idioma diferente, o usando un hardware diferente, etc. Esto se estaba desarrollando nuevamente usando Java, usando Tuxedo, etc. No lo veo como una solicitud.
Jerry Coffin

28

Legado significa cualquier código que prefiera reemplazar en lugar de trabajar. Dada la actitud de la mayoría de los programadores hacia la mayoría del código existente, eso generalmente incluye casi todo, excepto lo que está escribiendo activamente en este momento (y en un proyecto grande donde tiene que codificar un diseño congelado, incluso lo que está escribiendo en el momento puede ser incluido también).

  1. El énfasis "más bien" tiene la intención de transmitir que el código heredado también significa que está atrapado trabajando con él aunque prefiera no hacerlo. Sin embargo, no estoy seguro de que el énfasis fuera suficiente. Las razones para eso pueden variar. Algunos realmente son demasiado grandes y complejos para reemplazarlos. Otros son interfaces con otros sistemas. Aún otros son impulsados ​​por la política y las personalidades (por ejemplo, el código es horrible, pero el stand de bebé fue increíble).
  2. Otro punto que quizás no haya enfatizado lo suficiente es que, si bien la calidad del código puede ser un factor, rara vez (si alguna vez) es el único factor, y a menudo ni siquiera es un factor particularmente importante.
  3. Creo que las personas que realizan pruebas unitarias como el único factor determinante son como el tipo que busca bajo la luz de la calle el arete que su esposa dejó caer a una cuadra de distancia. La luz puede ser mejor, pero aún estás buscando en el lugar equivocado. Piensa antes de beber el Kool-Aid .
  4. (Un corolario de 3.) Me parece que algunas personas están hablando más sobre cómo desearían que fueran las cosas que cómo realmente son. Si el Juego de la vida de John Conways para un Apple IIc Plus no es heredado, es porque es lo suficientemente pequeño y simple como para que sea fácil de implementar desde cero. La prueba de unidad más perfecta jamás escrita no cambiará eso ni un ápice .

El último punto lleva a otros dos puntos que creo que a menudo son ciertos.

Primero, el código a menudo se retiene como legado, incluso cuando realmente no debería serlo. Los gerentes de nivel superior generalmente asumen que volver a implementar un sistema costará tanto o más que la implementación inicial, lo que rara vez es cierto.

En segundo lugar, las pruebas unitarias son una espada de dos filos. Hacen que sea demasiado fácil pensar que los cambios localizados en la implementación son lo que realmente importa. Para realizar mejoras significativas en un sistema más grande, con frecuencia (¿generalmente?) Tiene que cambiar lo suficiente del diseño general que muchas (si no la mayoría) de las pruebas unitarias se vuelven irrelevantes. Desafortunadamente, la presencia de pruebas unitarias y la actitud que engendran pueden hacer que sea demasiado fácil ignorar los cambios que son realmente necesarios.

Quizás un ejemplo de eso ayudaría: supongamos que un programa tiene una biblioteca de interfaz de usuario con excelentes pruebas unitarias y varios programas que usan esa biblioteca. Alguien en la alta dirección se convence de que "web habilitado" es importante (y, solo por el argumento, supongamos que en este caso tiene razón al respecto). Después de una cuidadosa revisión, los gerentes intermedios encuentran que su prueba de unidad actual es suficiente para que puedan cambiar de una interfaz de usuario que se muestra a través de la capacidad de ventanas del sistema operativo local para que se muestre de forma remota a través de HTML / CSS / AJAX, mientras conservan toda la validación de entrada original.

Eso es genial, ¿no? Muestra cuán útiles pueden ser las pruebas unitarias. Hemos cambiado toda la implementación de la interfaz de usuario completa, pero nos aseguramos de que el aspecto, la sensación y la funcionalidad sigan siendo prácticamente consistentes, y todas las entradas del usuario se validan para garantizar la integridad de los datos. ¡Las pruebas unitarias han salvado el día!

¡O no! Esa gran biblioteca de interfaz de usuario altamente flexible y cuidadosamente probada ha ayudado a cegar a todos los involucrados ante el hecho de que para este programa en su mercado con sus usuarios, una interfaz de usuario basada en web es algo completamente incorrecto para trabajar. Lo que realmente se necesita es un servicio web con una interfaz RESTful y absolutamente ninguna interfaz de usuario propia.

Ahora, es cierto que las pruebas unitarias no eliminan, en sí mismas, la capacidad de las personas para comprender su mercado o darse cuenta de que es realmente necesario. Al mismo tiempo, la vieja línea sobre martillos y clavos prácticamente salta a la mente. Puede ser aún peor cuando no solo tiene un martillo, sino que tiene mucha experiencia con este martillo y sabe que es realmente un martillo de alta calidad que funciona increíblemente bien en muchas situaciones diferentes. El hecho mismo de que sea tan bueno en tantas cosas en tantas situaciones hace que sea aún más difícil reconocer cuándo es la herramienta completamente incorrecta para el trabajo en cuestión.


3
Mira, ahora no sé si marcar esto o no, lamentablemente esto es cierto, pero me pregunto si es una actitud de la que debemos alejarnos ...
Nim

+1. Estaba a punto de responder algo en la misma medida. Legacy es cualquier código que se usa en lugar de mantenerse activamente.
Denis de Bernardy

@Nim: No creo que sea una actitud de la que "nosotros" debamos alejarnos. Es una mera declaración de lo obvio. :-) Piénselo por un momento y pregúntese qué consideraría ser un código heredado si llegara a un nuevo entorno; será todo excepto las cosas nuevas y geniales que se están desarrollando activamente.
Denis de Bernardy

@Jerry, ¿entonces no te gustan las pruebas unitarias? ;)
Nim

1
@Nim: No es así, creo que son útiles, pero muy por debajo de la panacea como se retrata con frecuencia.
Jerry Coffin

17

El código heredado generalmente está huérfano de alguna manera. El desarrollador principal, el único que lo entendió, fue atropellado por un autobús, y sus notas fueron escritas en su dialecto nativo de Ucrania, que ahora es un idioma muerto. O, alternativamente, cualquier cosa escrita en Visual Basic 6.0 .

Trabajo en código heredado todo el tiempo. Yo diría que las características son:

  • No se puede extender sin un esfuerzo masivo
  • No se puede migrar fácilmente a un nuevo hardware
  • Es demasiado crítico para el negocio para ser reemplazado fácilmente

Si no tiene esas características, entonces probablemente no sea heredado. Si no le gustan los scripts de Perl de sus predecesores , lo compadezco, pero no creo que sea un legado. Recientemente modernicé un script de Perl de 15 años que estaba conectado a una base de datos Sybase obsoleta . Eso fue fácil en comparación con hacer incluso el más pequeño cambio en nuestro horrible sistema de contabilidad COBOL .


Miedo, nuestro desarrollador principal también es ucraniano ... jaja ... Estoy de acuerdo con la parte central de su respuesta, el primer punto, no tanto, creo que depende de cómo esté configurado su equipo de desarrollo.
Nim

1
jajaja, probablemente has logrado ofender (conductores de autobuses, idioma ucraniano y desarrolladores de VB6) en un solo párrafo. Pero maldita sea, me
reí

Soy un viajero del tiempo desde 1999, ¿quiere decir que Visual Basic 6 es legado desde 2011 en adelante?
hjk

@hjk Diría que casi cualquier cosa después del advenimiento de C # / asp.net en 2005 estaría en terreno inestable, pero ciertamente una vez que el fin del soporte de Microsoft llegara en 2008.
Satanicpuppy

12

En su libro, Working Effectively with Legacy Code , Michael Feathers define el código heredado como un código que no está cubierto con pruebas unitarias. Esa es una definición, con la que estoy de acuerdo. También veo el código heredado como antiguo, pero aún utilizable.


24
Esto me parece un caso de intentar definir "cualquier cosa que no siga mi metodología elegida" como "legado". No es más o menos que una táctica de debate barata, básicamente solo tomando la ley de Godwin y suavizando el lenguaje (apenas) lo suficiente como para evitar que los lectores reconozcan instantáneamente que no es más que un ataque sin apoyo (y a menudo insostenible) a cualquiera que no siga sus preferencias
Jerry Coffin

44
@ Jerry: Estoy de acuerdo con la definición de Feather. Code with Unit-Tests es un horror con el que trabajar. Si decides que quieres refactorizar algunas partes para que sea más fácil razonar sobre ello, ¡olvídalo! ¡puede estar introduciendo errores y el código probablemente no sea comprobable, de todos modos! Creo que la definición de Feather no es convencional, pero es alguien que se ganaba la vida trabajando con código heredado.
devorado elysium

10
@devoured: las pruebas unitarias no son una prueba de fuego precisa para determinar la capacidad de trabajar con código. He tratado con código que carecía de pruebas unitarias, pero fue muy fácil, y con código que tenía pruebas unitarias, y todavía era una pesadilla. En última instancia, las pruebas unitarias no resuelven nada en sí mismas. Las pruebas unitarias para un diseño en el que (por ejemplo) la división en unidades se realizó mal todavía puede ser completamente inútil, y todo el diseño (incluidas las pruebas) debe ser eliminado y reemplazado para producir algo útil.
Jerry Coffin

66
Estoy de acuerdo con los comentarios de Jerry. La ausencia de pruebas unitarias es solo uno de los muchos olores de código que podrían (o no ) indicar maldad.
smci

44
De nuevo estoy de acuerdo con la definición de Feather, así como devorado. La ausencia de prueba unitaria lo es todo, ya que esto significa que incluso el fragmento de código más hermoso no tiene sus especificaciones. Las pruebas unitarias son el 51% de la documentación y el 100% de la especificación del código. Un código que falta la mayor parte de su documentación y todas sus especificaciones deben clasificarse correctamente como heredadas.

8

Técnicamente, el legado es cualquier código que ya está escrito. Tan pronto como esté en producción, es legado. Debido a que ya hay valor allí, no puedes simplemente tirarlo ... Tienes que lidiar con eso.

Es "antes de tu tiempo" pero "sigue siendo tu dolor de cabeza" .


5

El código heredado es un código que solo permanece en la base del código porque, de lo contrario, muchas cosas dejarían de funcionar. En otras palabras: su única razón de ser es la compatibilidad con versiones anteriores.

Preferiría cambiarlo o incluso tirarlo a la basura, pero no puede porque romperá todo el código confiando en él (que podría ser un código que no puede adaptar en consecuencia). Por lo tanto, debe conservarlo (y a veces incluso mantenerlo), pero desea que no se escriba ningún código nuevo en su contra.

Un ejemplo son los métodos obsoletos de la API de una biblioteca. Todavía están allí, de modo que si quien actualiza la biblioteca aún puede construir su proyecto, pero están marcados como obsoletos y su compilador debería darle una advertencia.

Otro ejemplo son todos esos trucos extraños que Microsoft hace para ejecutar programas que fueron escritos para versiones de su sistema operativo que han desaprobado por completo. El pináculo de este ser:

Lo escuché por primera vez de uno de los desarrolladores del exitoso juego SimCity, quien me dijo que había un error crítico en su aplicación: usaba memoria justo después de liberarlo, un gran no-no que funcionó bien en DOS, pero no funcionaría en Windows, donde es probable que otra aplicación en ejecución se apodere de la memoria liberada de inmediato. Los probadores del equipo de Windows estaban revisando varias aplicaciones populares, probándolas para asegurarse de que funcionaban bien, pero SimCity seguía fallando. Informaron esto a los desarrolladores de Windows, que desmontaron SimCity, lo revisaron en un depurador, encontraron el error y agregaron un código especial que verificó si SimCity se estaba ejecutando y, si lo hizo, ejecutó el asignador de memoria en un modo especial en el que Todavía podría usar la memoria después de liberarla.
- Joel en software


4

El legado implica herencia. El código heredado es simplemente un código que heredas del pasado. ¡Es un código heredado incluso si lo escribió usted mismo antes!

Todas las demás consideraciones se derivan básicamente del hecho de que no lo escribió específicamente para su proyecto actual. No es necesariamente algo malo per se.


El pasado podría ser 1 día, 1 hora o 1 año. Eso no lo hace legado.
Vince Panuccio

2

Mi opinión es que lo que se considera código heredado depende de varias cosas, y la etiqueta 'legado' probablemente sea específica de la organización.

Si el hardware / sistema operativo en el que se ejecuta es antiguo y ha sido descontinuado por el vendedor, pulse 1.

Si es más difícil tratar de arreglarlo, que reescribirlo, por cualquier motivo porque

  • los desarrolladores originales se han ido
  • el programa está mal escrito
  • se puede hacer mejor en una plataforma más nueva y todavía vale la pena para la empresa

para hacerlo

  • la fuente original ya no está disponible y / o piezas faltantes

Huelga 2.

Una fusión de múltiples organizaciones en una sola - Strike 3 - un lado probablemente será etiquetado como legado.

¿Existe una alternativa mejor y más barata que se venda como una aplicación y / o servicio de terceros?

¿Es la organización algo así como un hospital o un distrito escolar donde se valora la coherencia sobre las nuevas tecnologías en lo que respecta a las operaciones diarias? Tomará más tiempo para que una aplicación se considere heredada en comparación con la misma aplicación en una organización comercial / competitiva.

Si la empresa es una pequeña empresa de desarrollo que sigue mejorando / apoyando la aplicación para hacer lo que los clientes necesitan, ¿se considera código heredado o simplemente código 'antiguo'? Conozco una empresa llamada Mc2Ok: desarrollaron el software en lo que parece haber sido Windows 3.1, y lo han seguido llevando adelante. Todavía tiene una apariencia de Windows 3.1, pero también le agregaron una interfaz web. Es una compañía de desarrolladores de dos hombres (supongo), y diría que cuando dejen de trabajar en ella, se considerará legado y tiempo para migrar un año o dos después si la usa. Pero eso podría ser otros 10 o más años.

A veces, cuando la administración cambia, puede cambiar en oleadas que tienen muchos efectos de goteo ... Dependiendo de la influencia de la nueva administración, puede hacer que muchas aplicaciones sean heredadas y que de otra manera estarían bien.

Creo que cada organización debe definir qué significa para ellos el "código heredado". Solía ​​mirar los clasificados de The Sunday Times todas las semanas para ver qué buscaban las organizaciones. Ese solía ser mi barómetro para lo que ya no era relevante (es decir, legado). Bueno, The Sunday Times ya no es relevante :-) Y podemos generalizar que COBOL es legado, ASP Classic es legado, etc. Pero creo que cada organización tiene que decidir cuándo una aplicación se considera legada.


+1, buena respuesta: mejor considerar algo heredado desde la perspectiva de la organización ...
Nim

0

El código es heredado cuando uno tiene miedo de cambiarlo, porque puede romperlo. Es aún más doloroso cuando todo el sistema puede verse afectado por cambios en ese código.

Es por eso que también estoy de acuerdo con la definición de Michael Feathers. El código que tiene buenas pruebas unitarias se puede cambiar sin miedo.

También creo que el código heredado no tiene nada que ver con la antigüedad. Uno puede escribir código heredado desde el principio.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.