Refactorización: ¿no es solo una palabra elegante para limpiar su código? [cerrado]

Antes de que saliera el libro de Martin Fowler "Refactorización: Mejorando el diseño del código existente", solíamos llamar a los cambios importantes a la "rearquitectura" del código y a los cambios menores "limpieza". En mi opinión, las técnicas de refactorización son cosas de sentido común / obvias que hemos estado haciendo desde siempre.

¿Crees que la refactorización alguna vez fue algo nuevo? ¿Quizás solo una forma de engañar a la administración para que asigne tiempo para la limpieza del código?

La refactorización es más antigua que las colinas, así que no, no es nada nuevo.

Y refactorizar no es limpiar. Bueno, puede ser, pero no se limita a limpiar.

Está ajustando la arquitectura de su aplicación (ya sea a gran o pequeña escala) mientras preserva el comportamiento.

Eso significa que si bien parte de su aplicación pudo haber estado perfectamente limpia y bien ayer, la nueva característica de hoy requiere ajustar esa parte para acomodar la nueva característica.

No desea romper la funcionalidad existente, por lo que ajusta la estructura de su aplicación mientras preserva el comportamiento, que es la refactorización.

Dicho esto, no importa qué cambios se realicen en el código, uno siempre debe ejecutar sus pruebas ... por si acaso.

Solo está ordenando el código. Esencialmente, los programadores (especialmente Martin Fowler) notaron que tendían a realizar las mismas tareas cada vez que ordenaban su código. Definieron y etiquetaron los métodos de limpieza y los problemas de código asociados y ¡listo! La refactorización nació.

Es lo mismo con los patrones de diseño: las personas notaron que tendían a usar los mismos enfoques para problemas particulares una y otra vez. Etiquetaron y definieron los enfoques y ahora parece que no eres un programador real a menos que solo uses la misma docena de patrones en tu código.

No hay magia para refactorizar; Es solo un nuevo conjunto de jerga para describir una vieja práctica.

Hacemos tres cosas separadas en nuestra empresa, con tiempo asignado para las tres:

• Refactorización: consiste en cambiar la estructura del código, manteniendo así el comportamiento.

Ejemplo: dividir un método de 100 líneas feo e ilegible que hace cuatro cosas en cuatro métodos reutilizables, 25 líneas cada uno.

• Limpieza: consiste en realizar modificaciones menores para hacer que el código sea más legible sin modificar ni su comportamiento ni su estructura.

Ejemplo: eliminar el código comentado después de asegurarse de que este código ya no es necesario.

• Hacer cumplir las reglas StyleCop / FxCop: consiste en verificar si el código coincide con el conjunto predeterminado de reglas StyleCop o FxCop, y si no, modificarlo para que coincida con esas reglas.

Ejemplo: añadir Culture.Invarianten string.Format(o otra cultura que es más apropiado).

Entonces, en mi caso, la refactorización es algo muy diferente de la limpieza . Al hacer la limpieza, no tengo para ejecutar pruebas unitarias de nuevo: si el código trabajó antes, va a trabajar después de la limpieza. En otras palabras, no es porque eliminé una línea vacía o agregué un comentario que el código dejará de funcionar. Por otro lado, cuando refactorizo ​​partes complicadas de un código antiguo, puedo cometer algunos errores, por lo que debo ejecutar pruebas unitarias después de refactorizar.

La refactorización agrega conocimiento a su código. Si sabe que algo tiene un nombre incorrecto, le dará un nombre mejor. Si sabes que algo se puede hacer mejor, lo cambias a algo mejor.

Son muchos pasos, pequeños y grandes, que con suerte resultan en un mejor programa.

Estoy de acuerdo con "refactorizar es una palabra elegante para limpiar su código" pero no con "solo". Las personas usan palabras elegantes por una razón: a veces porque quieren parecer inteligentes, y otras porque están transmitiendo un significado mayor o más preciso, y la refactorización de la OMI (incluso si ocasionalmente se usa mal) generalmente se refiere a esto último.

"Limpiar" podría significar cualquier cosa, desde "reformatear un poco" hasta "reescribir fragmentos grandes".

"Refactorización" significa específicamente algo así como "pequeños cambios incrementales en el código, diseñados para mantener la misma funcionalidad, mientras se transforma en un mejor diseño". Y hay un conjunto de mejores prácticas sobre el tipo de cosas que haces: algunas son ad-hoc, pero hay principios generales, como el uso de pruebas unitarias, la extracción de parte de funciones en nuevas funciones o clases, etc., que las personas pueden y deben aprender .

Usted dice "simplemente engañe a la administración para que asigne tiempo para la limpieza del código". Pero si decir "refactorización" transmite correctamente el concepto de que una inversión constante en claridad ahora pagará dividendos en eficiencia en el futuro, entonces eso no es un "truco", es una comunicación clara y efectiva.

Refactorizar es codificar como Normalización es a datos relacionales. Es un proceso de abstracción de conceptos en representaciones más limpias, más claras y más eficientes de su papel en la aplicación.

Depende de cómo se entienda la refactorización de términos. Para la mayoría de las personas, este es un proceso para mejorar la estructura sin cambiar el comportamiento. Si está de acuerdo, entonces sí, se hizo mucho antes de que saliera este libro. Lo sé, porque estaba (entre muchas otras cosas) renombrando clases, extrayendo clases y extrayendo métodos antes de que se escribiera el libro. No lo llamaba refactorización, pero en esencia estaba haciendo exactamente lo mismo.

Para mí, la refactorización personal es lo que la gente ahora llama "refactorización de código automatizada", es decir: soporte para diversas técnicas de refactorización dentro de un IDE. Esta es una mejora real de lo que estaba haciendo antes (que de hecho fue muy doloroso). Puedo realizar un cambio en una clase y no preocuparme de cómo esto afectará al resto del software. Creo que Martin formalizó la técnica de refactorización hasta el punto en que podría representarse como algoritmo y, por lo tanto, implementarse en varios IDE.

Entonces, si entiendes la refactorización como un proceso, entonces no es nada nuevo. Si lo ves como automatización, entonces sí, es una gran mejora. Intente renombrar algunas clases principales (literalmente, no a través de las opciones de refactorización de su IDE) en un proyecto razonablemente grande para ver por qué :)

La refactorización es, de hecho, la "limpieza" del código, pero también la reestructuración del código. En mi equipo, la refactorización suele ser la última. Cuando tenemos un caso de "refactorización", asignamos tiempo para reestructurar nuestro código, por ejemplo, para alinearlo con una nueva arquitectura o modelo de información, o para hacerlo más eficiente.

La "limpieza" del código es algo que hacemos continuamente sin un tiempo especialmente asignado para ello. Para mí, "limpieza" suele ser renombrar, eliminar comentarios, etc.

Yo diría que no.

Puede haber limpieza en el proceso de refactorización, pero no es la esencia.

La limpieza viene con la suposición de que el código anterior no está limpio. En realidad, los desarrolladores refactorizan su código, incluso el código original ya está limpio.

DRY es una unidad clave detrás de la refactorización.

Al agregar nuevos códigos a una base de código existente, la refactorización se realiza naturalmente debido al principio DRY.

Solo mi 0.02

Limpiar su código es como ordenar su casa, refactorizar es como derribar una pared y posiblemente colocarla en otro lugar

Cuando alguien más limpia su casa, no puede encontrar nada porque el objetivo es limpiar las cosas y quitarlas del camino. La refactorización construiría y etiquetaría habitaciones, armarios, armarios, estantes, papeleras, etc. Todavía contiene la mayoría de las mismas cosas (todavía puede hacer un sándwich de queso a la parrilla en la cocina y comerlo en la sala de estar), pero debe hacerlo más fácil de encontrar y posiblemente tener lugares eficientes para poner cosas nuevas.

El término 'refactorización' está prestado elegantemente del álgebra. Significa simplificar los términos para producir el mismo resultado. No solo elegante, fue revolucionario: requirió un enfoque finito y duro de su código, a un nivel que sorprendió a muchos. Y así, el término en sí fue significativo y útil.

No. Refactorizar es mejorar la estructura sin cambiar el comportamiento. Refactorizar en sentido estricto implica una buena disciplina de prueba. Eso no es necesariamente necesario cuando "limpia las cosas".

Los dos se superponen un poco en los bordes, pero para mí es la diferencia entre limpiar la casa y remodelarla. La limpieza, para mí, no implica cambios estructurales, mientras que la refactorización sí.

La "refactorización" es realmente lo mismo que la "rearquitectura", pero con una connotación más fuerte de "sin cambios en la funcionalidad". También es más claro en términos del objetivo de la re-arquitectura, que a menudo es "factorizar" el código común en fragmentos reutilizables.