¿Cuál es la diferencia entre refactorizar, rediseñar, rediseñar y reescribir?

Antes de enfocarnos en las diferencias, señalemos la similitud obvia: el prefijo común “re”. Juntas, especialmente con la inclusión de “refactorización”, estas palabras hablan sobre cambiar algunos software existentes.

Mantendré la palabra refactorizando para el final, porque esta tiene un significado bastante específico en el contexto de la agilidad. No estoy seguro de que tenga algún significado fuera de ese contexto.

Las otras tres palabras señalan diferentes escalas de software.

Los programadores están usando la palabra Arquitectura para describir cómo (grandes) partes del software están trabajando juntas para lograr el objetivo deseado. Por lo tanto La reestructuración significa grandes cambios de código que pueden ser necesarios para solucionar problemas serios.

El diseño también apunta a la estructura del software pero a menor escala. A menudo se usa para API y, por supuesto, también se usa para componentes de interfaz de usuario. El rediseño puede usarse, por ejemplo, para describir cambios en la API o cambios en la capa de interacción del usuario.

La reescritura es bastante genérica, pero generalmente se usará para una escala aún más pequeña. Los programadores normalmente reescribirán una función, para reemplazarla con un código con suerte mejor.

Todo esto no dice nada sobre la forma en que haces las cosas. Se trata de cambiar, esperemos lo mejor, y generalmente porque se descubrió algún problema en el software existente, pero realmente sin ningún seguro de que estos cambios mejorarán algo.

La refactorización es mucho más específica. En el contexto de la agilidad, esto es algo que haces en el código que está cubierto por las pruebas unitarias. La refactorización no debe cambiar nada del comportamiento del programa (no romper ninguna prueba) sino mejorar el software desde el punto de vista del mantenimiento. Se realiza mediante la detección de patrones formales (anti) en los síntomas del código fuente de problemas más profundos, conocidos como olores de código, y luego aplicando cambios formales correspondientes. La idea subyacente es que al aplicar muchos cambios tan pequeños, surgirá un proceso más simple y eficiente. En realidad, funciona bastante bien y está mucho más bajo control que los otros cambios ciegos anteriores.

En otras palabras, desde mi punto de vista, la refactorización está bien, mientras que la reestructuración, el rediseño o la reescritura son banderas rojas. Con la excepción, tal vez, del rediseño aplicado a la interfaz de usuario (y aun así, sigo creyendo que tal vez también haya formas más controladas para eso y la aparición de una mejor interfaz de usuario a través de los comentarios de los usuarios parece más racional).

En la práctica, estas palabras se usan indistintamente. Pero si obtuviera su significado real diría:

  1. Refactorizar se referiría a reorganizar el código de su proyecto. Digamos que no está satisfecho con la estructura de código de su proyecto (tal vez porque no es lo suficientemente modular, o tiene mucha duplicación de código, etc.) y desea reorganizarlo. Eso es lo que yo llamaría refactorización. La refactorización puede o no conducir a ganancias de rendimiento, y puede hacerse para que la base del código sea más legible o mantenible.
  2. Usaría la reorganización y el rediseño en el mismo contexto. Esto se usa cuando realiza cambios tecnológicos en su proyecto que pueden llevarlo a ganancias de rendimiento o una mejor escalabilidad. Ejemplo: supongamos que desea cambiar de una base de datos relacional a noSQL, por lo que es posible que deba rediseñar la capa de servicio de datos en su código. O supongamos que desea cambiar la arquitectura de su proyecto a una distribuida.
  3. La reescritura se puede usar en el mismo contexto que la reestructuración. De lo contrario, usaría la reescritura cuando alguien reescriba algún proyecto de manera diferente desde cero para cumplir el mismo propósito. Obviamente, puede ver que implicaría volver a diseñar todo el proyecto.