refactoring rewrite

refactoring - Reescribir o reparar?



rewrite (11)

Dependiendo de su situación, es posible que tenga 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".

Estoy seguro de que todos ustedes han estado allí, se encargan de un proyecto en el que hay una base de código viejo y crujiente que apenas se adapta a sus necesidades, y 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 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ó?

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

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

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

Donde trabajo reescribí 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 se creó

Realmente depende de lo malo que sea.

Si es un sistema pequeño, y lo entiendes 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 misterioso no documentado, entonces realmente vas a tener un momento difícil con una reescritura completa.

Puntos a considerar:

  • Si se ve bien para el usuario, no le importará qué tipo de lío de spaghetti sea para usted. Por otro lado, si también es malo para ellos, entonces es más fácil llegar a un acuerdo (y paciencia).
  • Si lo vuelve a escribir, intente hacerlo una parte a la vez. Una base de código desordenada y desorganizada puede dificultar esto (es decir, reemplazar solo una parte requiere una reescritura de grandes icebergs de código de dependencia), pero si es posible, esto hace que sea mucho más fácil hacer la reescritura y obtener retroalimentación de los usuarios a lo largo del 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.

Recomiendo leer "Working Effectively with Legacy Code" de Michael Feathers. Es un consejo de entrenamiento sobre cómo refactorizar su código para que pueda ser probado por la unidad.

Refactor a menos que sea muy malo.

Joel tiene mucho que decir sobre esto ...

Por lo menos, reescriba el código con el código anterior frente a usted y no comience 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.

Reparar, o más importante, refactorizar. Tanto porque Joel así lo dijo como porque, si es tu código, probablemente hayas aprendido muchas más cosas 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 ocurre 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.

Simplemente limpie 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 las limpiezas progresen, podrás barrer cada vez más el 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 son bastante fuertes. Esas toneladas de "pequeños errores" y comportamientos que fueron codificados durante el período de tiempo del proyecto original volverán a entrar.

Una razón para reescribir en uno de mis trabajos anteriores fue la incapacidad de encontrar desarrolladores con suficiente experiencia 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.

Todavía no he escuchado 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.

Vea el ensayo de Joel Spolsky Cosas que nunca debe hacer . 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.

Ver también: Big Ball of Mud