¿Existe algún punto en el que el costo de la refactorización supere el costo de la reescritura?

Question

Tenemos un código realmente impactante promocionado como un marco de próxima generación en mi lugar de trabajo actual.

La cosa es que solo hay una persona de esta opinión y ese es el tipo que escribió la mayor parte. El resto del departamento tiene la impresión de que está mal codificado, es un pita para depurar y un poco malo en general.

El hombre que lo escribió tiene una posición bastante influyente con la administración por lo que están en ese lado del campamento.

Hemos puesto de manifiesto preocupaciones (genuinas) para la gerencia, pero obviamente no están dispuestas a dedicar más tiempo a un proyecto que no contribuye directamente al resultado final.

Hay varias aplicaciones implementadas en este marco por lo que cualquier refactorización deberá abarcar esas aplicaciones.

Todo el asunto está tan entrelazado que no podemos arrancar una implementación de una clase en particular y reescribirla de esa manera, por lo que incluso los cambios simples a la API básica significan un gran proyecto.

Sin embargo, tiene 3 años en implementación en vivo y muchas correcciones de errores, casos de esquina y condiciones de contorno atendidas.

¿Reescribimos en partes y tratamos de refactorizarlo en vista de que se trataría de varios proyectos de gran envergadura, de refactorización a lo largo del tiempo que probablemente demorará otros 3 años en ponerse en forma o simplemente reescribiremos nuestros requisitos específicos en parte superior de un marco existente?

Answer 1

Reescribir algo es casi universalmente una mala idea: pasas meses trabajando, sin nada que mostrar hasta que hayas terminado. Y eso supone que no caes preso del efecto del segundo sistema, y ​​que en realidad terminas .

Refactorizar es casi seguro que la respuesta correcta. No tengo experiencia en la refacturación de PHP (hago C++ y C#), así que no puedo ofrecer ningún consejo específico. Tienes que seguir pasos de bebé.

• Primero, identifique las partes del código que más le ofenden. Para mí, en C++, esto son variables globales.
• En segundo lugar, realice pequeñas refactorizaciones para eliminar un problema a la vez. Con el fin de evitar romper los clientes más antiguos de ese código, es posible que deba colocar una fachada en su lugar. O puede poner una nueva fachada en el código anterior, o puede colocar una fachada anterior en el nuevo código.
• En tercer lugar, y lo más importante, a menos que sea realmente seguro, asegúrese de que tiene un conjunto sólido de pruebas de unidad para el código que está a punto de refactorizar.

Pero: no deje todo para volver a escribir el código. Refactor gradualmente Te ralentizará un poco, pero seguirás entregando valor a medida que avanzas.

Ver this article que le ayudará a explicar la deuda técnica a su gestión. También explicará por qué no parece importarles.

Answer 2

que es una decisión difícil real para hacer ...

problema que veo aquí es, que el marco se utiliza y se fija durante mucho tiempo por lo que hay una gran cantidad de conocimiento entró en ella y la calidad de la gestión proyectos es obviamente aceptable.por lo tanto, si vuelve a escribir desde cero con todos los requisitos que conoce, puede estar seguro de que olvidará algo que ya funcionó (difícil de explicar a un cliente o a su jefe;))

refactorización it-it creo - es también una tarea difícil ya que sólo hay un tipo que realmente conoce las conexiones dentro del código - que no quiere cambiarlo ...

hay tres opciones:

• vivir con ella
• convencer al tipo que la refactorización es necesaria para que todos puedan usarla/mantenerla no solo a él
• convencer a la dirección que es necesaria una reescritura, pero esto hará que el que está en contra de una reescritura/refactorización muy molesto

de cualquier manera lo pones - es una situación mala para todo el mundo ... ya que con el tiempo pasando por el responsable del marco tendrá que lidiar con él mismo y entonces es probable que sea demasiado tarde.

Answer 3

La ventaja de reescribir es que puede tener en cuenta todo lo nuevo en la fase de análisis, crear un modelo más adaptado a las necesidades actuales. Por otro lado, si solo está mal codificado, no mal diseñado, no tiene sentido hacer una reescritura completa. Solo desinfecte/refactorice el código.

Answer 4

En un nivel pequeño, sí: proporcione una nueva versión de una función, verifique que funcione tanto con la nueva como con la antigua, elimine la antigua. Eso es a menudo más rápido que refactorizar el funciton mismo. Pero en ese nivel, está refactorizando :)

estratégico El costo de una reescritura virtualmente siempre excede la refactorización.

No puede entregar. Tienes que mantener la versión anterior mientras desarrollas la nueva. Si las finanzas dicen que tienes que matar el proyecto de reescritura, no has logrado nada: tu base de código de trabajo está en mal estado como si nunca se hubiera hecho nada. Probablemente sea aún peor, ya que todos los cambios se aplicaron porque "lo descartaremos cuando la reescritura termine de todos modos".

---

Sí escenarios donde la reescritura es más barato se puede construir:

• la base de código original es tan spaghettied que las características de los saltos de modificación de locales aparentemente no relacionados.
• Tienes un equipo realmente nuevo, mucho mejor que los viejos, pero no tienen experiencia con la base de códigos existente, y la base de códigos existente es un desastre, o en un idioma que no conocen, o algo como eso.

---

Sin embargo, la experiencia demuestra que el código es mala por una razón, y no siempre los codificadores, y cuando no se identifica y cambiar las causas, la reescritura habrá un ejercicio de repetición de la historia.

Answer 5

Reescribir es muy arriesgado. Reemplazará el código antiguo bien depurado con un código nuevo que aún debe ser depurado. Esto introducirá una gran cantidad de errores y tendrás que arreglarlos. Es mejor refactorizar gradualmente: primero debe comprender en detalle para qué sirve una parte y luego refactorizarla. De esta manera, reemplazas menos código y reduces el riesgo de introducir demasiados errores nuevos.

Answer 6

Para agregar a lo que ya se ha dicho: intente obtener la aceptación de la administración. Hay son beneficios de en la línea de fondo cuando se refactoriza: las horas de trabajo para programar nuevas funciones disminuirán con el tiempo en lugar de aumentar, lo que reduce los costos salariales y posiblemente también los costos del servidor. Si ninguno de sus directivos comprende por qué la refacturación vale la pena y lo hará más feliz haciendo su trabajo, ¿está trabajando en el lugar correcto?