regalo - codigos de legacy of discord

¿Qué se puede hacer con una base de código heredada que tendrá el mayor impacto en la mejora de la calidad?

Question

A medida que trabaje en una base de código heredada, ¿qué tendrá el mayor impacto a lo largo del tiempo que mejorará la calidad de la base de código?

• Eliminar el código no utilizado
• Eliminar el código duplicado
• Agregue pruebas unitarias para mejorar la cobertura de prueba donde la cobertura es baja
• Crea un formato consistente en todos los archivos
• Actualizar software de terceros
• Reducir las advertencias generadas por las herramientas de análisis estático (es decir, errores de la falsa)

La base de código ha sido escrita por muchos desarrolladores con diferentes niveles de experiencia durante muchos años, con muchas áreas sin probar y otras no evaluables sin pasar un tiempo significativo en la redacción de pruebas.

Answer 1

Agregue pruebas unitarias para mejorar la cobertura de la prueba. Tener una buena cobertura de prueba le permitirá refactorizar y mejorar la funcionalidad sin temor.

Hay un buen libro escrito por el autor de CPPUnit, Working Effectively with Legacy Code .

Agregar pruebas al código heredado es ciertamente más desafiante que crearlas desde cero. El concepto más útil que he sacado del libro es la noción de "costuras", que Feathers define como

"un lugar donde puedes modificar el comportamiento en tu programa sin editarlo en ese lugar".

A veces vale la pena refactorizar para crear las costuras que harán que las pruebas futuras sean más fáciles (o posibles en primer lugar). El blog de pruebas de google tiene varias publicaciones interesantes sobre el tema, en su mayoría relacionadas con el proceso de Dependency Injection .

Answer 2

Diría que depende en gran medida de lo que quieras hacer con el código heredado ...

Si permanece indefinidamente en modo de mantenimiento y funciona correctamente, no hacer nada es la mejor opción. "Si no está roto, no lo arregles".

Si no funciona bien, eliminar el código no utilizado y refactorizar el código duplicado facilitará la depuración. Sin embargo, solo haría estos cambios en el código erróneo.

Si planea usar la versión 2.0, agregue pruebas unitarias y limpie el código que presentará

Answer 3

Puedo relacionarme con esta pregunta ya que actualmente tengo en mi regazo uno de "esos" códigos escolares de la vieja escuela. No es realmente legado, pero ciertamente no siguió la tendencia de los años.

Te diré las cosas que me gustaría solucionar, ya que me molestan todos los días:

• Documentar las variables de entrada y salida
• Refactorice los nombres de las variables para que realmente signifiquen algo diferente y algún prefijo de notación húngaro seguido de un acrónimo de tres letras con algún significado oscuro. CammelCase es el camino a seguir.
• Tengo miedo de cambiar cualquier código, ya que afectará a cientos de clientes que usan el software y alguien notará incluso el efecto secundario más oscuro. Cualquier prueba de regresión repetible sería una bendición ya que ahora hay cero.

El resto es realmente maní. Estos son los principales problemas con una base de código heredada, realmente consumen mucho tiempo.

Answer 4

Yo diría ''eliminar código duplicado'', más o menos significa que tienes que extraer el código y extraerlo para poder usarlo en varios lugares; esto, en teoría, hace que los errores sean más fáciles de solucionar porque solo tienes que arreglar una parte del código. , a diferencia de muchos fragmentos de código, para corregir un error.

Answer 5

• Lea el libro de Michael Feather "Working effective with Legacy Code"

Este es un gran libro.

Si no te gusta esa respuesta, entonces el mejor consejo que puedo dar sería:

• Primero, deja de crear un nuevo código heredado [1]

[1]: código heredado = código sin pruebas unitarias y, por lo tanto, desconocido

Cambiar el código heredado sin un conjunto de pruebas automatizado es peligroso e irresponsable. Sin una buena cobertura de prueba unitaria, es imposible saber qué efecto tendrán esos cambios. Feathers recomienda un enfoque de "dominio absoluto" donde se aíslan las áreas de código que necesita cambiar, se escriben algunas pruebas básicas para verificar las suposiciones básicas, se realizan pequeños cambios respaldados por pruebas unitarias y se resuelve a partir de allí.

NOTA: No digo que deba detener todo y pasar semanas escribiendo pruebas para todo. Muy por el contrario, solo prueba alrededor de las áreas que necesitas probar y resolver desde allí.

Jimmy Bogard y Ray Houston hicieron una proyección de pantalla interesante sobre un tema muy similar a esto: http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/05/06/pablotv-eliminating-static-dependencies-screencast. aspx

Answer 6

Buena documentación. Como alguien que tiene que mantener y extender el código heredado, ese es el problema número uno. Es difícil, si no francamente peligroso, cambiar el código que no comprende. Incluso si tiene la suerte de recibir un código documentado, ¿qué tan seguro está de que la documentación es correcta? ¿Que cubre todo el conocimiento implícito del autor original? ¿Que habla de todos los "trucos" y casos extremos?

Una buena documentación es lo que permite a quienes no sean el autor original comprender, corregir y extender incluso el código incorrecto. Tomaré un código pirateado pero bien documentado que puedo entender con un código perfecto pero inescrutable cualquier día de la semana.

Answer 7

Trabajo con una aplicación legacy 1M LOC escrita y modificada por unos 50 programadores.

* Remove unused code

Casi inútil ... solo ignóralo. No obtendrá un gran retorno de la inversión (ROI) de ese.

* Remove duplicated code

En realidad, cuando arreglo algo siempre busco duplicados. Si encuentro alguna, pongo una función genérica o comento toda la ocurrencia de código para la duplicación (alguna vez, el esfuerzo para poner una función genérica no vale la pena). La idea principal es que odio hacer la misma acción más de una vez. Otra razón es porque siempre hay alguien (podría ser yo) que se olvida de buscar otra ocurrencia ...

* Add unit tests to improve test coverage where coverage is low

Las pruebas unitarias automatizadas son maravillosas ... pero si tienes un gran retraso, la tarea en sí es difícil de promover a menos que tengas problemas de estabilidad. Vaya con la parte en la que está trabajando y espere que en unos pocos años tenga una cobertura decente.

* Create consistent formatting across files

IMO la diferencia en el formateo es parte del legado. Le da una pista sobre quién o cuándo se escribió el código. Esto puede darle alguna pista sobre cómo comportarse en esa parte del código. Hacer el trabajo de reformatear no es divertido y no le da ningún valor a su cliente.

* Update 3rd party software

Hazlo solo si hay nuevas funciones realmente interesantes o si la versión que tienes no es compatible con el nuevo sistema operativo.

* Reduce warnings generated by static analysis tools

Puede valer la pena. En algún momento, la advertencia puede ocultar un posible error.

Answer 8

Como un paralelo a lo que Josh Segall dijo, yo diría que comenten el infierno. He trabajado en varios sistemas heredados muy grandes que se volcaron en mi regazo, y encontré que el problema más grande era hacer un seguimiento de lo que ya había aprendido sobre una determinada sección de código. Una vez que comencé a colocar notas sobre la marcha, incluidas las notas "Tareas pendientes", dejé de volver a descubrir lo que ya había averiguado. Entonces podría centrarme en cómo fluyen e interactúan esos segmentos de código.

Answer 9

Lo más importante que he hecho con el código heredado con el que tengo que trabajar es crear una API real a su alrededor. Es una API COBOL de estilo de los 70 que construí un modelo de objetos .NET para que todo el código inseguro esté en un solo lugar, toda la traducción entre los tipos de datos nativos de la API y los tipos de datos .NET está en un lugar, el los métodos principales devuelven y aceptan DataSets, y así sucesivamente.

Esto fue inmensamente difícil de hacer bien, y todavía hay algunos defectos que conozco. Tampoco es tremendamente eficiente, con toda la clasificación que se lleva a cabo. Pero, por otro lado, puedo construir un DataGridView que redirija los datos a una aplicación de 15 años que persista en Btrieve (!) En aproximadamente media hora, y funciona. Cuando los clientes vienen a mí con proyectos, mis estimaciones son en días y semanas en lugar de meses y años.

Answer 10

Yo diría que simplemente lo dejo en su mayor parte. Si no está roto, no lo arregles. Si está roto, prosiga y solucione y mejore la parte del código que se rompe y su código que lo rodea inmediatamente. Puede usar el dolor del error o la característica que le falta gravemente para justificar el esfuerzo y el gasto de mejorar esa parte.

No recomendaría ningún tipo de reescritura, refactorización, reformateo o instalación mayorista de pruebas unitarias que no estén guiadas por las necesidades reales del negocio o del usuario final.

Si tiene la oportunidad de arreglar algo, hágalo bien (la posibilidad de hacerlo bien la primera vez ya pudo haber pasado, pero ya que está tocando esa parte otra vez también podría hacerlo bien en el tiempo) y esto incluye todo los artículos que mencionaste

Entonces, en resumen, no hay solo o solo algunas cosas que debes hacer. Deberías hacerlo todo, pero en pequeñas porciones y de manera oportunista.

Answer 11

Tarde en la fiesta, pero puede valer la pena hacer lo siguiente cuando se usa o referencia una función / método:

• Las variables locales a menudo tienden a ser mal nombradas en el código heredado (a menudo debido a que su alcance se expande cuando se modifica un método y no se actualiza para reflejar esto). Cambiar el nombre de estos en línea con su propósito real puede ayudar a aclarar el código heredado.
• Incluso el simple hecho de diseñar el método de forma ligeramente diferente puede hacer maravillas, por ejemplo, poner todas las cláusulas de un if en una línea.
• Puede que ya existan comentarios de código obsoletos / confusos. Quítelos si no los necesita, o enmiéndelos si es absolutamente necesario. (Por supuesto, no estoy abogando por la eliminación de comentarios útiles, solo aquellos que son un obstáculo).

Estos pueden no tener el impacto general masivo que está buscando, pero son de bajo riesgo, especialmente si el código no puede ser probado en unidades.