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

Question

Al trabajar en una base de código heredada, ¿qué tendrá el mayor impacto en el tiempo que mejorará la calidad de la base de código?

• Eliminar código no utilizado
• Eliminar código duplicado
• Agregue pruebas unitarias para mejorar la cobertura de pruebas donde la cobertura es baja
• Crear un formato coherente en todos los archivos
• Actualizar software de terceros
• Reduzca las advertencias generadas por las herramientas de análisis estático (es decir, Findbugs)

La base de código ha sido escrita por muchos desarrolladores con diferentes niveles de experiencia durante muchos años, con muchas áreas no probadas y otras no probables sin gastar un tiempo significativo en escribir pruebas.

Answer 1

• Lea el libro de Michael Feather " Trabajando eficazmente con el Código heredado "

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, un desconocido

Cambiar el código heredado sin un conjunto de pruebas automatizado es peligroso e irresponsable. Sin una buena cobertura de prueba unitaria, no se puede saber qué efecto tendrán esos cambios. Feathers recomienda un " estrangulamiento " enfoque donde se aíslan las áreas de código que necesita cambiar, escriba algunas pruebas básicas para verificar suposiciones básicas, realice pequeños cambios respaldados por pruebas de unidad y haga ejercicio desde allí.

NOTA: No estoy diciendo que deba detener todo y pasar semanas escribiendo exámenes para todo. Muy por el contrario, solo realice pruebas alrededor de las áreas que necesita probar y ejercite desde allí.

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

Answer 2

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

* Remove unused code

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

* Remove duplicated code

En realidad, cuando arreglo algo, siempre busco duplicado. Si encontré alguna, puse una función genérica o comenté la aparición de todo el código para la duplicación (en algún momento, el esfuerzo por 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 verificar otra ocurrencia ...

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

Las pruebas unitarias automatizadas son maravillosas ... pero si tiene un gran atraso, la tarea en sí es difícil de promover a menos que tenga un problema 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

OMI, la diferencia en el formato es parte del legado. Le da una pista sobre quién o cuándo se escribió el código. Esto puede darte una pista sobre cómo comportarte en esa parte del código. Hacer el trabajo de reformateo, no es divertido y no le da ningún valor a su cliente.

* Update 3rd party software

Hazlo solo si el nuevo sistema operativo no admite una característica realmente interesante o si la versión que tienes no es compatible.

* Reduce warnings generated by static analysis tools

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

Answer 3

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 sobre esto escrito por el autor de CPPUnit, Trabajando efectivamente con el código heredado .

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 alterar el comportamiento en tu programa sin editar en ese lugar. "

A veces vale la pena refactorizar la creación de costuras que facilitarán las pruebas futuras (o posibles en primer lugar). El google blog de prueba tiene varias publicaciones interesantes sobre el tema, que giran en torno al proceso de Inyección de dependencia .

Answer 4

Yo diría que 'eliminar código duplicado' significa que tienes que sacar el código y abstraerlo para que se pueda usar en múltiples lugares. Esto, en teoría, hace que los errores sean más fáciles de solucionar porque solo tienes que corregir uno Parte del código, a diferencia de muchas partes del código, para corregir un error en él.

Answer 5

Puedo relacionarme con esta pregunta, ya que actualmente tengo en mi primera vuelta la base de código de 'esos' de la vieja escuela. No es realmente un legado, pero ciertamente no ha seguido la tendencia de los años.

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

• Documentar las variables de entrada y salida
• Refactoriza los nombres de las variables para que en realidad signifiquen algo diferente y algún prefijo de notación húngara 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 cacahuetes. Estos son los principales problemas con una base de código heredada, realmente consumen toneladas de tiempo.

Answer 6

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

Si permanecerá indefinidamente en modo de mantenimiento y funcionará bien, no hacer nada en absoluto es su mejor apuesta. " Si no está roto, no lo arregles "

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

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

Answer 7

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 completamente peligroso cambiar el código que no entiendes. 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 los casos de borde?

Una buena documentación es lo que permite que aquellos que no son el autor original comprendan, corrijan y extiendan incluso el código incorrecto. Tomaré un código hackeado pero bien documentado que puedo entender sobre un código perfecto pero inescrutable cualquier día de la semana.

Answer 8

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 COBOL API de estilo de los años 70 en la que he creado un modelo de objeto .NET, de modo 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 solo lugar, la los métodos primarios devuelven y aceptan DataSets, etc.

Esto fue muy difícil de hacer bien, y todavía hay algunos defectos que conozco. Tampoco es tremendamente eficiente, con todo el ordenamiento que ocurre. Pero, por otro lado, puedo construir un DataGridView que redondea los datos a una aplicación de 15 años de antigüedad que conserva sus datos en Btrieve (!) En aproximadamente media hora, y funciona. Cuando los clientes acuden a mí con proyectos, mis estimaciones son en días y semanas en lugar de meses y años.

Answer 9

Paralelamente a lo que dijo Josh Segall, yo diría que coméntalo todo. He trabajado en varios sistemas heredados de gran tamaño que se descargaron en mi regazo, y descubrí que el mayor problema era hacer un seguimiento de lo que ya había aprendido acerca de una sección particular del código. Una vez comencé a colocar notas a medida que avanzaba, incluyendo " To Do " notas, dejé de volver a averiguar lo que ya había descubierto. Entonces podría centrarme en cómo esos segmentos de código fluyen e interactúan.

Answer 10

Yo diría que simplemente dejarlo solo en su mayor parte. Si no está roto, entonces no lo arregles. Si está roto, siga adelante, arregle y mejore la parte del código que está roto y su código inmediatamente circundante. Puedes usar el dolor del error o la característica que te falta para justificar el esfuerzo y el gasto de mejorar esa parte.

No recomendaría ningún tipo al por mayor de reescritura, refactorización, reformateo o realización de pruebas unitarias que no estén guiadas por la necesidad real del negocio o del usuario final.

Si tiene la oportunidad de arreglar algo, entonces hágalo bien (la posibilidad de hacerlo bien la primera vez puede que ya haya pasado, pero ya que está tocando esa parte nuevamente, también puede hacerlo en el momento adecuado) y esto incluye todos los artículos que mencionaste.

En resumen, no hay una sola cosa o solo algunas cosas que debes hacer. Debe hacerlo todo, pero en pequeñas porciones y de manera oportunista.

Answer 11

Llega tarde a la fiesta, pero vale la pena hacer lo siguiente cuando una función / método se usa o hace referencia a menudo:

• Las variables locales a menudo tienden a tener un mal nombre 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 de acuerdo con su propósito real puede ayudar a aclarar el código heredado.
• Incluso el hecho de presentar el método de manera ligeramente diferente puede hacer maravillas, por ejemplo, poner todas las cláusulas de un si en una línea.
• Puede que ya haya comentarios de código obsoletos / confusos. Elimínelos si no son necesarios, o modifíquelos si es absolutamente necesario. (Por supuesto, no estoy abogando por la eliminación de comentarios útiles, solo aquellos que son un obstáculo).

Es posible que no tengan el impacto masivo de titulares que estás buscando, pero son de bajo riesgo, especialmente si el código no puede ser probado por la unidad.