¿Cuándo es “legado” el código? [cerrado]

Soy bastante parcial a resumen de Wikipedia :

  

Un sistema heredado es un método antiguo, una tecnología, un sistema informático o un programa de aplicación que se sigue utilizando, generalmente porque aún funciona para las necesidades de los usuarios, aunque ahora se cuenta con una tecnología más reciente o métodos más eficientes para realizar una tarea. disponible.

Gran parte de lo que otras personas están describiendo en sus respuestas son razones por las que 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, ¿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.

Hay varias razones por las que los sistemas o el código podrían hacerse heredados:

• Falta de mantenimiento regular o pudrición del software . Claramente, si la aplicación no se mantiene con regularidad, no seguirá el ritmo de los cambios importantes en el mundo del software. Esto podría deberse a un simple abandono o podría 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 cualquier código no cubierto por Pruebas siendo código legado. 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, liderando así la "putrefacción del software".

• El bloqueo de revoluciones, un factor que a menudo se pasa por alto y es particularmente insidioso en los proyectos que utilizan 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 del marco / biblioteca, lo que hace 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 y nunca cambiar. Dado que estos sistemas se deben reescribir para actualizar, en lugar de ser revisados de forma incremental / 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:

  

¿Debemos 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í mismo implica claramente que el código funciona. El punto no es que es función, sino cómo está funcionando.

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

Legacy se vuelve obsoleto cuando el sistema ya no puede atender (todas) las necesidades del cliente. Esa etiqueta es una 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 se reserva para "auditoría fiscal". Es una situación perfectamente aceptable para estar.

Por lo general, significa que está escrito en un idioma o en función de un sistema en el que normalmente no haces nuevos desarrollos.

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".

Legado significa cualquier código que prefiera reemplazar en lugar de trabajar con. 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 debe codificar un diseño congelado, incluso lo que está escribiendo en el el momento puede ser incluido también).

1. El énfasis "en lugar de" está destinado a transmitir que el código heredado también significa que estás atascado trabajando con él aunque prefieras no hacerlo. Aunque no estoy seguro de que el énfasis fuera suficiente. Las razones para eso pueden variar. Algunos realmente son demasiado grandes y complejos para reemplazar. Otros son interfaces a otros sistemas. Otros más son impulsados por la política y las personalidades (por ejemplo, el código es horrible, pero el stand 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 es que lo hay) es el único factor, y con frecuencia ni siquiera uno especialmente importante.
3. Creo que las personas que presionan pruebas de unidad como el único factor determinante único son como el tipo Mirando a la luz de la calle por el pendiente, su esposa dejó caer una manzana. La luz puede ser mejor, pero todavía estás buscando en el lugar equivocado. Piensa antes de bebe 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 son realmente. Si John Conways ' Game of Life para un Apple IIc Plus no es un legado, es porque es lo suficientemente pequeño y sencillo. que es fácil volver a implementar desde el principio. La prueba de unidad más perfecta que se haya escrito nunca cambiará una sola iota .

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

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

Segundo, las pruebas unitarias son una espada de dos filos. Hacen que sea muy 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 (¿en general?) Tiene que cambiar lo suficiente del diseño general para que muchas (si no la mayoría) de las pruebas unitarias se vuelvan irrelevantes. Desafortunadamente, la presencia de pruebas unitarias y la actitud que generan pueden hacer que sea muy fácil ignorar los cambios que son realmente necesarios.

Quizás un ejemplo de eso ayudaría: supongamos que un programa tiene una biblioteca UI con excelentes pruebas de unidad, y varias Programas que utilizan esa biblioteca. Alguien en la alta gerencia se convence de que "habilitar la web" es importante (y, solo por el bien de la discusión, supongamos que en este caso en realidad tiene razón). Después de una revisión cuidadosa, los gerentes intermedios encuentran que sus pruebas de unidad actuales son suficientes para que puedan cambiar de una interfaz de usuario que se muestra a través de la capacidad de ventanas del sistema operativo local a que se muestre de forma remota a través de HTML / CSS / AJAX, mientras se mantiene toda la validación de entrada original.

Eso es genial, ¿no? Muestra lo útiles que pueden ser las pruebas unitarias. Hemos intercambiado la implementación completa de toda la interfaz de usuario, pero nos aseguramos de que la apariencia, la sensación y la funcionalidad permanezcan virtualmente consistentes y que todas las aportaciones de los usuarios se validen para garantizar la integridad de los datos. ¡Las pruebas unitarias han salvado el día!

¡O no! Esa gran biblioteca de UI altamente flexible y cuidadosamente probada por unidad ha ayudado a cegar a todos los involucrados al hecho de que para este programa en su mercado con sus usuarios, una UI basada en la web es completamente incorrecto para trabajar. Lo que realmente se necesita es un servicio web con una interfaz RESTful y una interfaz de usuario absoluta de no es propio en absoluto.

Ahora, es cierto que las pruebas unitarias no eliminan 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 virtualmente salta a la mente. Puede ser incluso peor cuando no solo tienes un martillo, sino que tienes un montón de experiencia con este martillo, y sabes que es realmente un martillo de alta calidad que funciona increíblemente bien en muchas situaciones diferentes. El solo hecho de que sea tan bueno en tantas cosas en tantas situaciones hace que sea aún más difícil reconocerlo cuando se trata de la herramienta equivocada para el trabajo en cuestión.

El código heredado generalmente se queda 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 ucraniano, que ahora es una lengua muerta. O, alternativamente, cualquier cosa escrita en Visual Basic 6.0 .

Trabajo en el 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 te gustan los scripts Perl de tus predecesores, simpatizo, pero no creo que sea un legado. Recientemente modernicé algunas secuencias de comandos de Perl de 15 años que estaban relacionadas con una base de datos obsoleta Sybase . Ese fue un pastel en comparación con hacer el cambio más pequeño en nuestro terrible sistema de contabilidad COBOL .

En su libro, Trabajando de manera efectiva con el código heredado , Michael Feathers define el código heredado como un código que no está cubierto con las 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.

Técnicamente, legado es cualquier código que esté listo para escribir. Tan pronto como está en producción, es legado. Porque 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" .

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

Prefieres cambiarlo o incluso desecharlo, pero no puedes porque romperás todo el código que se basa en él (que podría ser un código que no puedes adaptar). Por lo tanto, debe conservarlo (ya veces incluso mantenerlo), pero desea que no se escriba todo el código nuevo en su contra.

Un ejemplo son 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á marcado como obsoleto y el compilador debería avisarle.

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

  

Escuché esto 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:   usó la memoria justo después de liberarla, un gran no-no que sucedió a   funciona bien en DOS pero no funcionaría en Windows donde la memoria es   liberado es probable que sea arrebatado por otro derecho de aplicación en ejecución   lejos. Los evaluadores en el equipo de Windows estaban pasando por varios   aplicaciones populares, probándolas para asegurarse de que funcionaron bien, pero   SimCity siguió chocando. Informaron esto a los desarrolladores de Windows,   quien desmontó SimCity, lo atravesó en un depurador, encontró el   error, y agregó un código especial que verificaba 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

El legado implica herencia. El código heredado es simplemente el código que heredas del pasado. Es un código heredado, incluso si lo escribiste tú 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.

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

Si el hardware / sistema operativo en el que se ejecuta es antiguo y ha sido descontinuado por el proveedor - strike 1.

Si es más trabajo 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 compañía

para hacerlo

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

Golpea 2.

La fusión de varias organizaciones en una - Strike 3 - un lado probablemente se etiquetará como legado.

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

¿Es la organización algo así como un hospital o un distrito escolar donde la coherencia se valora sobre la nueva tecnología cuando se trata de las operaciones diarias? Tomará más tiempo que una aplicación se considere legada 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 / dando soporte a la aplicación para hacer lo que los clientes necesitan, ¿se considera un código heredado o simplemente un código 'antiguo'? Conozco a una compañía llamada Mc2Ok: desarrollaron el software en lo que parece haber sido Windows 3.1 y lo siguieron llevando a cabo. Todavía tiene una apariencia de Windows 3.1, pero también le agregaron una interfaz web. Es una empresa desarrolladora de dos hombres (supongo), y diría que cuando dejen de trabajar en ella, se considerará como un legado y el tiempo para migrar uno o dos años después de usarlo. 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 generar muchas aplicaciones heredadas que de otro modo podrían estar bien.

Creo que cada organización tiene que 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 heredado, ASP Classic es heredado, etc. Pero creo que cada organización debe decidir cuándo una solicitud se considera legada para ella.

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 ser afectado por cambios en ese código.

Por eso 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.