¿Reescribir o reparar?

Question

Estoy seguro de que todos han estado allí, se encargan de un proyecto en el que hay una base de código viejo y crujiente que apenas se ajusta a sus necesidades y que deben tomar la decisión de volver a escribir desde cero o reparar lo que ya existe

La sabiduría convencional tiende a sugerir que nunca se debe intentar volver a escribir desde cero, ya que el riesgo de falla es muy alto. Entonces, ¿qué hizo cuando se enfrentó a este problema, cómo tomó la decisión y cómo resultó?

Answer 1

Realmente depende de qué tan malo sea.

Si se trata de un sistema pequeño, y lo comprende completamente, entonces una reescritura no es una locura.

Por otro lado, si se trata de un monstruo legado gigante con diez millones de líneas de código de misterio no documentado, entonces realmente vas a tener un momento difícil con una reescritura completa.

Los puntos a considerar:

• Si se ve bien para el usuario, que no importa qué tipo de espaguetis lío que es para usted. En la otra mano , si también es malo para ellos, entonces es más fácil obtener un acuerdo (y paciencia).
• Si lo vuelve a escribir, intente hacerlo una parte a la vez. A, código base desorganizado desordenado puede hacer que este difícil (es decir, la sustitución de un solo parte requiere una reescritura de grandes icebergs de código de la dependencia), pero si posible, esto hace que sea mucho más fácil hacer gradualmente la reescritura y obtener comentarios de los usuarios en el camino.

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

Answer 2

No es tan blanco y negro ... En realidad depende de muchos factores (la más importante de las cuales "lo que hace la persona que paga usted quiere que haga")

Donde trabajo nos re-escribimos 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, tratamos de mantener el estilo de codificación y, a veces, debe implementar muchas soluciones debido a la forma en que fue construido

Answer 3

Refactor a menos que sea muy malo.

Joel has a lot to say on this...

Por lo menos, volver a escribir el código con el código antiguo frente a ti y no empezar de nuevo desde cero. El código anterior puede ser terrible, pero es así por una razón y si lo ignoras terminarás viendo los mismos errores que probablemente se arreglaron hace años en el código anterior.

Answer 4

Véase el ensayo de Joel Spolsky Things You Should Never Do. En resumen, cuando reescribe pierde todas las lecciones que aprendió para hacer que su código actual funcione de la manera que necesita para funcionar.

Consulte también: Big Ball of Mud

Answer 5

Sólo limpiar el código un poco cada vez que trabaje con él. Si aún no hay uno, configure un marco de prueba de unidades. Todo el código nuevo debe tener pruebas escritas. Cualquier código antiguo que arregles como resultado de errores, intenta deslizarte también en las pruebas.

A medida que avanza la limpieza, podrá barrer más y más del código desagradable en contenedores encapsulados. Entonces puedes elegirlos uno por uno en el futuro.

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

Los argumentos en contra de una reescritura completa una muy fuerte. Esas toneladas de "pequeños errores" y comportamientos que fueron codificados durante el período de tiempo del proyecto original volverán a entrar.

Answer 6

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

Se tomó la decisión de primero limpiar la estructura de la base de datos subyacente, luego reescribir en algo que haría más fácil encontrar empleados y/o contratistas a tiempo completo.

no he oído todavía cómo funcionaba fuera :)

Creo que las personas tienen una tendencia a ir para reescrituras porque parece más divertido en la superficie.

¡Reconstruimos desde cero!

Lo haremos bien esta vez!

etc.

Answer 7

Es raro que una re-escritura de nada complejo para tener éxito. Es tentador, pero una estrategia de bajo porcentaje.

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

Answer 8

Hay un nuevo libro que sale, Brownfield Application Development in .NET por Baley and Belcham. El primer capítulo es gratuito y habla sobre estos temas desde una perspectiva agnóstica en su mayoría plataforma.

Answer 9

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

He consultado en un par de empresas donde esa sería la elección sensata, aunque aparentemente "tirar la IP" puede ser una gran barrera para la administración. En mi compañía actual, consideramos seriamente la opción viable de usar código de terceros para reemplazar nuestro marco central, pero esa idea finalmente fue rechazada más por razones comerciales que por razones técnicas.

Para responder directamente a su pregunta, finalmente elegimos reescribir el marco heredado, una decisión que no tomamos a la ligera. 14 meses después, no nos arrepentimos de esta elección. Solo teniendo en cuenta el tiempo dedicado a corregir errores, nuestro nuevo marco casi se ha pagado solo. En el lado negativo, todavía no es completamente funcional, 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 10

Le recomiendo leer "Trabajando eficazmente con código heredado" de Michael Feathers.Es un consejo de entrenamiento sobre cómo refactorizar su código para que pueda ser probado por la unidad.

Answer 11

Reparar o, lo que es más importante, refactorizar. Tanto porque Joel said so como porque, si es tu código, probablemente hayas aprendido muchísimo más desde que tocaste este código al final. Si lo escribió en .NET 1.1, puede actualizarlo a 3.5 SP1. Tienes que entrar y purgar todo el viejo código comentado. Estás 100 veces mejor como desarrollador ahora que cuando primero escribiste este código.

La única excepción que creo que es cuando el código usa tecnologías realmente anticuadas, en cuyo caso sería mejor si escribes una nueva versión. Si estás viendo alguna aplicación VB6 con 10,000 líneas de código con un back-end de base de datos Access obviamente creado por alguien que no sabía mucho sobre cómo funcionan las bases de datos (que bien podrías ser hace ocho años), entonces probablemente puedas tirar de una solución más rápida, basada en C#/SQL en una fracción del tiempo y el código.