¿Reescribir o reparar?

Question

Estoy seguro de que todos habéis pasado por eso, asumís un proyecto en el que hay un código base antiguo y chirriante que apenas sirve para su propósito y tenéis que tomar la decisión de reescribirlo desde cero o reparar lo que ya existe.

La sabiduría convencional tiende a sugerir que nunca se debe intentar reescribir desde cero ya que el riesgo de fracaso es muy alto.Entonces, ¿qué hiciste ante este problema, cómo tomaste la decisión y cómo resultó?

Answer 1

Realmente depende de lo malo que sea.

Si es un sistema pequeño y lo comprende completamente, entonces reescribirlo no es una locura.

Por otro lado, si se trata de un monstruo heredado gigante con diez millones de líneas de código misterioso indocumentado, entonces realmente te resultará difícil reescribirlo por completo.

Puntos a considerar:

• Si se ve bien para el usuario, no le importará qué tipo de espagueti Es un desastre para ti.Por otro lado, mano, si también es malo para ellos, entonces Es más fácil llegar a un acuerdo (y paciencia).
• Si reescribes, intenta hacerlo de una manera parte a la vez.Un desordenado, La base de código desorganizada puede hacer que esto difícil (es decir, reemplazar solo uno parte requiere una reescritura de icebergs del código de dependencia), pero si posible, esto lo hace mucho más fácil para hacer gradualmente la reescritura y obtener comentarios de los usuarios a lo largo del camino.

Realmente dudaría en emprender un proyecto de reescritura gigante para un sistema grande sin poder lanzar la nueva edición parte a la vez.

Answer 2

Simplemente limpia el código un poco cada vez que trabajes con él.Si aún no existe uno, configure un marco de pruebas unitarias.Todo el código nuevo debe tener pruebas escritas.Cualquier código antiguo que corrija como resultado de errores, intente incluir pruebas también.

A medida que avancen las limpiezas, podrá barrer más y más código desagradable en contenedores encapsulados.Luego podrás eliminarlos uno por uno en el futuro.

Una herramienta como javadoc o doxygen, si aún no está en uso, también puede ayudar a mejorar la documentación y la comprensión del código.

Los argumentos en contra de una reescritura completa son bastante sólidos.Esas toneladas de "pequeños errores" y comportamientos que se codificaron durante el período de tiempo del proyecto original volverán a aparecer.

Answer 3

Ver el ensayo de Joel Spolsky Cosas que nunca debes hacer.En resumen, cuando reescribe, pierde todas las lecciones que aprendió para que su código actual funcione como debe funcionar.

Ver también: Gran bola de barro

Answer 4

Es raro que una reescritura de algo complejo tenga éxito.Es tentador, pero es una estrategia de bajo porcentaje.

Obtenga código heredado bajo pruebas unitarias y refactorícelo, y/o reemplace completamente pequeñas porciones de manera incremental cuando sea oportuno.

Answer 5

Refactorice a menos que sea realmente muy malo.

Joel tiene mucho que decir al respecto...

Como mínimo, reescribe el código con el código anterior frente a ti y no empieces de nuevo desde cero.El código antiguo puede ser terrible, pero es así por una razón y si lo ignoras terminarás viendo los mismos errores que probablemente se solucionaron hace años en el código antiguo.

Answer 6

Una razón para reescribir en uno de mis trabajos anteriores fue la incapacidad de encontrar desarrolladores con suficiente experiencia para trabajar en el código base original.

Se tomó la decisión de limpiar primero la estructura de la base de datos subyacente y luego reescribir algo que facilitara la búsqueda de empleados y/o contratistas de tiempo completo.

Aún no he oído cómo funcionó :)

Creo que la gente tiende a reescribir porque parece más divertido en la superficie.

¡Podemos reconstruir desde cero!

lo haremos bien esta vez!

etc.

Answer 7

Hay un nuevo libro por salir, Desarrollo de aplicaciones brownfield en .NET por Baley y Belcham.El primer capítulo es gratuito y habla sobre estos temas desde una perspectiva mayoritariamente independiente de la plataforma.

Answer 8

Reparar, o más importante aún, refactorizar.Ambos porque joel lo dijo y también porque, si es tu código, probablemente hayas aprendido muchas más cosas desde la última vez que tocaste este código.Si lo escribió en .NET 1.1, puede actualizarlo a 3.5 SP1.Puedes entrar y eliminar todo el código antiguo comentado.Eres 100 veces mejor como desarrollador ahora que cuando escribiste este código por primera vez.

Creo que la única excepción es cuando el código utiliza tecnologías realmente anticuadas, en cuyo caso sería mejor escribir una nueva versión.Si está viendo alguna aplicación VB6 con 10,000 líneas de código con un backend de base de datos de Access obviamente configurado por alguien que no sabía mucho sobre cómo funcionan las bases de datos (que bien podría ser usted hace ocho años), entonces probablemente pueda extraer obtenga una solución más rápida basada en C#/SQL en una fracción del tiempo y el código.

Answer 9

No es tan blanco y negro...Realmente depende de muchos factores (el más importante es "¿qué quiere que hagas la persona que te paga?")

Donde trabajo reescribimos un marco de desarrollo y, por otro lado, seguimos modificando algunos sistemas antiguos que no se pueden migrar (debido a la tecnología del cliente y las restricciones de tiempo).En este caso, intentamos mantener el estilo de codificación y, a veces, es necesario implementar muchas soluciones debido a la forma en que se creó.

Answer 10

Dependiendo de su situación, usted podría tienes otra opción:código de terceros en licencia.

He consultado con un par de empresas donde esa sería la opción sensata, aunque aparentemente "desperdiciar la propiedad intelectual" puede ser una gran barrera para la gestión.En mi empresa actual, consideramos seriamente la opción viable de utilizar código de terceros para reemplazar nuestro marco central, pero esa idea finalmente fue rechazada más por razones comerciales que técnicas.

Para responder directamente a su pregunta, finalmente decidimos reescribir el marco heredado, ¡una decisión que no tomamos a la ligera!14 meses después, no nos arrepentimos en absoluto de esta elección.Si consideramos el tiempo dedicado a corregir errores, nuestro nuevo marco casi se amortizó solo.En el lado negativo, aún no tiene todas las funciones completas, por lo que estamos en la posición poco envidiable de mantener dos marcos separados en paralelo hasta que podamos portar la última de nuestras aplicaciones "front-end".

Answer 11

Recomiendo encarecidamente leer "Trabajar eficazmente con código heredado" de Michael Feathers.Es un consejo de entrenamiento sobre cómo refactorizar su código para que sea comprobable por unidad.